From vincent at clarinet.u-strasbg.fr Tue Sep 1 01:01:14 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Tue, 01 Sep 2009 10:01:14 +0200 Subject: [Ns-developers] IPv6 longest prefix match and metrics Message-ID: <4A9CD4CA.4040103@clarinet.u-strasbg.fr> Hi, I see that patch from Antti Makela that add metrics and longest prefix match for IPv4 static routing has been merged to ns-3-dev. I will try to find some time this week to add its IPv6 counterpart. Regards, -- Sebastien Vincent From andreev at iitp.ru Tue Sep 1 01:53:41 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Tue, 01 Sep 2009 12:53:41 +0400 Subject: [Ns-developers] AODV Implementation in NS-3 Message-ID: >>> hi, >>> >>> On Fri, 2009-06-19 at 11:19 -0400, David Liu wrote: >>> > When will AODV be supported in NS-3? >>> >>> When you send us a patch :) >>> >>> More seriously, I am not aware of anyone working on aodv support for >>> ns-3. >> >> We plan (though I can't really promise this) to port ns-2 aodv model till >> September. Stay tuned. >> >> Best reards, >> Pavel Boyko, IITP > > >Hello > >Is anyone aware of any progress being made with the task of >implementing AODV routing in NS3? >I ask because I am interested in adopting this problem as part of my project. > >It is still listed in the project ideas wiki page for the gsoc2009 >students, and i don't believe any of the 3 gsoc students took this >project. > >I suppose the main question is whether Pavel Boyko has ported the >model like he said he may. > >Regards >Ian AODV is alomost implemented. It will be available about a month later. Regards, Kirill Andreev, IITP RAS From faker.moatamri at sophia.inria.fr Tue Sep 1 03:14:35 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 01 Sep 2009 12:14:35 +0200 Subject: [Ns-developers] Few days before Wimax release Message-ID: <4A9CF40B.5000409@sophia.inria.fr> Hi all, The time schedule for wimax was: - September 1st: release of a patch based on ns-3-dev latest version As of today, we fixed all issues regarding the integration of wimax with ns-3-dev main tree and I would like to thank all those that contributed in developing/maintaining and debugging of the wimax module. However, we will need few more days to further clean the code and add some small features. The release is now expected to happen on Thursday september 3rd. Best regards Faker Moatamri From gjcarneiro at gmail.com Tue Sep 1 04:01:58 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 1 Sep 2009 12:01:58 +0100 Subject: [Ns-developers] Ipv4L3Protocol tracing enhancements, for FlowMonitor Message-ID: Please consider reviewing this patch: http://codereview.appspot.com/110125 -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From amine.ismail at sophia.inria.fr Tue Sep 1 04:14:42 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 01 Sep 2009 13:14:42 +0200 Subject: [Ns-developers] Debugging wimax-simple In-Reply-To: <4A9BA658.7070102@sophia.inria.fr> References: <4A9BA658.7070102@sophia.inria.fr> Message-ID: <4A9D0222.809@sophia.inria.fr> Hi Faker, Please find attached a patch fixing PR#670 Regards Amine Faker Moatamri wrote: > Hi, > I'm currently debugging wimax-simple program, I found the following: > -in wimax-helper.cc, device->Start () at line 261 is causing the crash > (coming from wimax-simple.cc line 143 and 144, the call to wimax.Install) > -in connection-identifier-factory.cc line 52, this call is causing a > crash (high level call: wimax.SetupConnection at lines 184 and 202 of > wimax-simple.cc) > Any idea Amine of what is happening? > Thanks > Faker Moatamri -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090901/d1601983/patch-0001.ksh From mk.banchi at gmail.com Tue Sep 1 05:07:32 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Tue, 1 Sep 2009 14:07:32 +0200 Subject: [Ns-developers] Review block ack patch #1 Message-ID: Hi Mathieu and all, This is the first patch for block ack: the implementation of block ack headers. These headers could be useful also to a possible A-MPDU developer. I don't know if you prefer perform review by e-mail. Let me know. Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090901/a04a1772/smime.bin From mk.banchi at gmail.com Tue Sep 1 06:14:02 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Tue, 1 Sep 2009 15:14:02 +0200 Subject: [Ns-developers] Problems with attachements? Message-ID: <48305997-8065-4760-AB9A-BA03BE8953E1@gmail.com> Mathieu, did you receive patch #1 for block ack? I've verified it was present also in the first e-mail i send, and i don't know why it wasn't there as attachment... Sorry for the trouble. Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090901/6eaae0f3/smime.bin From ian.thomson at gmail.com Tue Sep 1 08:05:55 2009 From: ian.thomson at gmail.com (Ian Thomson) Date: Tue, 1 Sep 2009 16:05:55 +0100 Subject: [Ns-developers] [NS-Developers] Reactive Routing Protocols: DSR routing Message-ID: <20a651590909010805i58b73be2hd3e1b78d374a3680@mail.gmail.com> Hi Is there anyone currently working on implementing DSR routing in NS3? As I would be interested in doing this for a project if not. Regards Ian Thomson From tomh at tomh.org Tue Sep 1 21:57:53 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 01 Sep 2009 21:57:53 -0700 Subject: [Ns-developers] Problems with attachements? In-Reply-To: <48305997-8065-4760-AB9A-BA03BE8953E1@gmail.com> References: <48305997-8065-4760-AB9A-BA03BE8953E1@gmail.com> Message-ID: <4A9DFB51.1040005@tomh.org> Mirko Banchi wrote: > Mathieu, did you receive patch #1 for block ack? I've verified it was > present also in the first e-mail i send, and i don't know why it wasn't > there as attachment... > > Sorry for the trouble. Can you check the mime type? For instance, Mathieu's post here: http://mailman.isi.edu/pipermail/ns-developers/2009-August/006362.html came through with Type: text/x-patch. But your posts just seem to have this attachment type: application/pkcs7-signature. Maybe the signature is interfering with the patch scrubbing? Tom From tomh at tomh.org Tue Sep 1 22:20:07 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 01 Sep 2009 22:20:07 -0700 Subject: [Ns-developers] Timers bug in ns2 ? In-Reply-To: References: Message-ID: <4A9E0087.9000707@tomh.org> ori and mish bgu wrote: > Dear ns developers > > We wrote our own mac layer that works similar to TDMA. > In our mac layer we generate ticks with timers of 1micro sec, means that > every 1micro sec the program goes into the tickHandler function. > > The basic idea: > > mhTick_.tick_start(0.0); > ... > > void MacMt::tickHandler(Event *e) > { > > .. our code .. > > printf("%.15f\n",NOW); > mhTick_.tick_start(0.000001); > } > > > But from some odd reason we found that it is not accurate ... ?! > the printed log shows that there is a drift of 1*10^(-15) every few hundreds > of ticks .. > The NOW macro returns a double, which on many systems has precision of about 16 decimal digits, and then you are passing it through printf to convert it to a string. Maybe it is a precision limit or some rounding due to conversion (don't know offhand). - Tom From mathieu.lacage at sophia.inria.fr Wed Sep 2 03:06:05 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 02 Sep 2009 03:06:05 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200909021006.n82A6505000419@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/140 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The web-page 'force build' button was pressed by 'wimax test': Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From mk.banchi at gmail.com Wed Sep 2 04:57:22 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Wed, 2 Sep 2009 13:57:22 +0200 Subject: [Ns-developers] Problems with attachements? In-Reply-To: <4A9DFB51.1040005@tomh.org> References: <48305997-8065-4760-AB9A-BA03BE8953E1@gmail.com> <4A9DFB51.1040005@tomh.org> Message-ID: <8693B0A8-F69A-4C36-9D12-68EE8701C2CB@gmail.com> Il giorno 02/set/09, alle ore 06:57, Tom Henderson ha scritto: > Mirko Banchi wrote: >> Mathieu, did you receive patch #1 for block ack? I've verified it >> was present also in the first e-mail i send, and i don't know why >> it wasn't there as attachment... >> Sorry for the trouble. > > Can you check the mime type? For instance, Mathieu's post here: > http://mailman.isi.edu/pipermail/ns-developers/2009-August/006362.html > came through with Type: text/x-patch. But your posts just seem to > have this attachment type: application/pkcs7-signature. Maybe the > signature is interfering with the patch scrubbing? > > Tom Hi, that's strange because second message (i sent two equal messages ) with the same mime type (application/pkcs7-signature) was received correctly. I can't figure out the reason. Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090902/83ab2373/smime.bin From mk.banchi at gmail.com Wed Sep 2 09:47:45 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Wed, 2 Sep 2009 18:47:45 +0200 Subject: [Ns-developers] Review block ack patch #1 In-Reply-To: <1251810626.3332.4.camel@diese.inria.fr> References: <1251809640.3332.1.camel@diese.inria.fr> <1251810626.3332.4.camel@diese.inria.fr> Message-ID: <62E0ECF0-BAAC-4B12-9682-05AE71283883@gmail.com> > Here is a very small patch that adds block ack support to MacLow::TransmissionParameters class. I think that it can be merged. What do you think about? Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090902/d9625953/smime.bin From mk.banchi at gmail.com Wed Sep 2 09:47:45 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Wed, 2 Sep 2009 18:47:45 +0200 Subject: [Ns-developers] Review block ack patch #1 In-Reply-To: <1251810626.3332.4.camel@diese.inria.fr> References: <1251809640.3332.1.camel@diese.inria.fr> <1251810626.3332.4.camel@diese.inria.fr> Message-ID: <62E0ECF0-BAAC-4B12-9682-05AE71283883@gmail.com> Here is a very small patch that adds block ack support to MacLow::TransmissionParameters class. I think that it can be merged. What do you think about? Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090902/d9625953/smime-0003.bin From renrengabas at gmail.com Wed Sep 2 00:26:10 2009 From: renrengabas at gmail.com (=?UTF-8?B?UmVuwrIgR2Fiw6Fz?=) Date: Wed, 2 Sep 2009 15:26:10 +0800 Subject: [Ns-developers] Timers bug in ns2 ? In-Reply-To: <4A9E0087.9000707@tomh.org> References: <4A9E0087.9000707@tomh.org> Message-ID: <3791cc4b0909020026u492d2196m813a5fb533426890@mail.gmail.com> It certainly looks like the precision limit of IEEE floating numbers. 2009/9/2 Tom Henderson > ori and mish bgu wrote: > >> Dear ns developers >> >> We wrote our own mac layer that works similar to TDMA. >> In our mac layer we generate ticks with timers of 1micro sec, means that >> every 1micro sec the program goes into the tickHandler function. >> >> The basic idea: >> >> mhTick_.tick_start(0.0); >> ... >> >> void MacMt::tickHandler(Event *e) >> { >> >> .. our code .. >> >> printf("%.15f\n",NOW); >> mhTick_.tick_start(0.000001); >> } >> >> >> But from some odd reason we found that it is not accurate ... ?! >> the printed log shows that there is a drift of 1*10^(-15) every few >> hundreds >> of ticks .. >> >> > The NOW macro returns a double, which on many systems has precision of > about 16 decimal digits, and then you are passing it through printf to > convert it to a string. Maybe it is a precision limit or some rounding due > to conversion (don't know offhand). > > - Tom > -- Data ? Information ? Knowledge ? Wisdom ? Enlightenment From buchner.johannes at gmx.at Tue Sep 1 22:18:00 2009 From: buchner.johannes at gmx.at (Johannes Buchner) Date: Wed, 2 Sep 2009 17:18:00 +1200 Subject: [Ns-developers] Spelling for the manual Message-ID: <20090902171800.3c0acf3d.buchner.johannes@gmx.at> Hi! I ran ispell over the manual after I saw a typo, so here is a patch that fixes some spelling mistakes. Please apply. Best regards, Johannes -- Emails k?nnen ge?ndert, gef?lscht und eingesehen werden. Signiere oder versch?ssele deine Mails mit GPG. http://web.student.tuwien.ac.at/~e0625457/pgp.html -------------- next part -------------- A non-text attachment was scrubbed... Name: mypatch Type: application/octet-stream Size: 33194 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090902/080220fe/mypatch-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090902/080220fe/attachment-0001.bin From nill_akaser_tara at yahoo.com Tue Sep 1 15:03:17 2009 From: nill_akaser_tara at yahoo.com (qweq adcsad) Date: Tue, 1 Sep 2009 15:03:17 -0700 (PDT) Subject: [Ns-developers] Timers bug in ns2 ? In-Reply-To: Message-ID: <504046.9444.qm@web62406.mail.re1.yahoo.com> First make the tick time 0 microsecond instead of 1 microsecond and check what is happening . Do it in the same computer. I think answer is there. --- On Mon, 8/31/09, ori and mish bgu wrote: > From: ori and mish bgu > Subject: [Ns-developers] Timers bug in ns2 ? > To: ns-developers at ISI.EDU > Date: Monday, August 31, 2009, 9:57 AM > Dear ns developers > > We wrote our own mac layer that works similar to TDMA. > In our mac layer we generate ticks with timers of 1micro > sec, means that > every 1micro sec the program goes into the tickHandler > function. > > The basic idea: > > mhTick_.tick_start(0.0); > ... > > void MacMt::tickHandler(Event *e) > { > > .. our code .. > > ? ? printf("%.15f\n",NOW); > ? ? mhTick_.tick_start(0.000001); > } > > > But from some odd reason we found that it is not accurate > ... ?! > the printed log shows that there is a drift of 1*10^(-15) > every few hundreds > of ticks .. > > part of the prints : > 0.000001000000000 > 0.000002000000000 > 0.000003000000000 > 0.000004000000000 > ... > 0.006358000000001 > 0.006359000000001 > 0.006360000000001 > .. > 0.032848000000012 > 0.032849000000012 > 0.032850000000012 > .. > 0.073830000000053 > 0.073831000000053 > 0.073832000000053 > 0.073833000000053 > ... > and it gets worse with time .. > 0.250990000000203 > 0.250991000000203 > 0.250992000000203 > 0.250993000000203 > .. ?? and drifts downwards too > 0.259740999999969 > 0.259741999999969 > 0.259742999999969 > > > Is it normal ? Or is it an ns2 bug ? > > Any help would be much appreciated > > Thanks in advance > Ori and Michael > From mihir.daftari at gmail.com Tue Sep 1 17:18:58 2009 From: mihir.daftari at gmail.com (Mihir Daftari) Date: Tue, 1 Sep 2009 20:18:58 -0400 Subject: [Ns-developers] Reactive Routing Protocols Message-ID: <83e334e50909011718w652b0492xb3c8e2494f018e7f@mail.gmail.com> Hi .. I read recently that there is some development going on AODV.. And someone seems interested in developing DSR. I would like to develop DYMO ( http://tools.ietf.org/html/draft-ietf-manet-dymo-17). It would use the new Generalized MANET Packet/Message format (packetBB) which I believe is under review and a possibility for 3.6? Is anyone else doing any work related to that? Thanks, Mihir On Tue, Sep 1, 2009 at 2:17 PM, wrote: > Send Ns-developers mailing list submissions to > ns-developers at isi.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.isi.edu/mailman/listinfo/ns-developers > or, via email, send a message with subject or body 'help' to > ns-developers-request at isi.edu > > You can reach the person managing the list at > ns-developers-owner at isi.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ns-developers digest..." > > > Today's Topics: > > 1. Review block ack patch #1 (Mirko Banchi) > 2. Problems with attachements? (Mirko Banchi) > 3. [NS-Developers] Reactive Routing Protocols: DSR routing > (Ian Thomson) > 4. Fwd: [patch] Helper methods for pcap tracing with explicit > filenames (Mart?n Ferrari) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 1 Sep 2009 14:07:32 +0200 > From: Mirko Banchi > Subject: [Ns-developers] Review block ack patch #1 > To: ns-developers mailing list > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi Mathieu and all, > > This is the first patch for block ack: the implementation of block ack > headers. These headers could be useful also to a possible A-MPDU > developer. > > I don't know if you prefer perform review by e-mail. Let me know. > > Thanks, > Mirko > > -- > Mirko Banchi > > e-mail: mk.banchi at gmail.com > e-mail: mk.banchi at virgilio.it > id-jabber: mk.banchi at jabber.org > > PGP key fingerprint: > > 308F BFB1 4E67 2522 C88E > DC69 7631 52ED 32A5 6456 > > > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2502 bytes > Desc: not available > Url : > http://mailman.isi.edu/pipermail/ns-developers/attachments/20090901/a04a1772/smime-0001.bin > > ------------------------------ > > Message: 2 > Date: Tue, 1 Sep 2009 15:14:02 +0200 > From: Mirko Banchi > Subject: [Ns-developers] Problems with attachements? > To: ns-developers mailing list > Message-ID: <48305997-8065-4760-AB9A-BA03BE8953E1 at gmail.com> > Content-Type: text/plain; charset="us-ascii" > > Mathieu, did you receive patch #1 for block ack? I've verified it was > present also in the first e-mail i send, and i don't know why it > wasn't there as attachment... > > Sorry for the trouble. > > Mirko > > -- > Mirko Banchi > > e-mail: mk.banchi at gmail.com > e-mail: mk.banchi at virgilio.it > id-jabber: mk.banchi at jabber.org > > PGP key fingerprint: > > 308F BFB1 4E67 2522 C88E > DC69 7631 52ED 32A5 6456 > > > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2502 bytes > Desc: not available > Url : > http://mailman.isi.edu/pipermail/ns-developers/attachments/20090901/6eaae0f3/smime-0001.bin > > ------------------------------ > > Message: 3 > Date: Tue, 1 Sep 2009 16:05:55 +0100 > From: Ian Thomson > Subject: [Ns-developers] [NS-Developers] Reactive Routing Protocols: > DSR routing > To: ns-developers at ISI.EDU > Message-ID: > <20a651590909010805i58b73be2hd3e1b78d374a3680 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > Is there anyone currently working on implementing DSR routing in NS3? > As I would be interested in doing this for a project if not. > > Regards > Ian Thomson > > > ------------------------------ > > Message: 4 > Date: Mon, 31 Aug 2009 19:41:02 +0200 > From: Mart?n Ferrari > Subject: [Ns-developers] Fwd: [patch] Helper methods for pcap tracing > with explicit filenames > To: craigdo at ee.washington.edu > Cc: ns-developers at ISI.EDU > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Resending with my other address, mailman doesn't like me :) > > > ---------- Forwarded message ---------- > From: Mart?n Ferrari > Date: Mon, Aug 31, 2009 at 18:11 > Subject: [patch] Helper methods for pcap tracing with explicit filenames > To: craigdo at ee.washington.edu > Cc: ns-developers at isi.edu > > > Hi Craig, > > For a project I'm working on, I need to set up pcap tracing while > being able to define exactly which filename the traces will have. Now, > the helper methods unconditionally append the node and device ids and > the ".pcap" suffix. I've created a patch that defines a new method > EnablePcapExplicit with exactly the same arguments as EnablePcap, but > doesn't append anything to the filename argument. ATM, I'd just > implemented overloaded methods for the nodeid+deviceid and device ptr > versions, but if you think it's worthwhile, I can add equivalent > methods for the other signatures of EnablePcap. > > I've also included the updated bindings for this. > > I'd like to ask you to consider merging this functionality. Maybe > you'd prefer a different method name, or some different organisation. > What I'd like to avoid is any diversion from the ns-3-dev main tree. > > Thanks, Mart?n. > > PS: please note that the current revision of ns-3-dev has some of the > bindings out of sync. When I run --python-scan, these files are > modified: > M bindings/python/ns3_module_core.py > M bindings/python/ns3_module_internet_stack.py > M bindings/python/ns3_module_wifi.py > > -- > Mart?n Ferrari > > > > -- > Mart?n Ferrari > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: add_explicit_pcaphelpers.patch > Type: text/x-patch > Size: 12086 bytes > Desc: not available > Url : > http://mailman.isi.edu/pipermail/ns-developers/attachments/20090831/cfd7fa86/add_explicit_pcaphelpers.bin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: bindings_explicit_pcaphelpers.patch > Type: text/x-patch > Size: 4679 bytes > Desc: not available > Url : > http://mailman.isi.edu/pipermail/ns-developers/attachments/20090831/cfd7fa86/bindings_explicit_pcaphelpers.bin > > ------------------------------ > > _______________________________________________ > Ns-developers mailing list > Ns-developers at isi.edu > http://mailman.isi.edu/mailman/listinfo/ns-developers > > > End of Ns-developers Digest, Vol 34, Issue 2 > ******************************************** > From amine.ismail at sophia.inria.fr Thu Sep 3 02:15:28 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 03 Sep 2009 11:15:28 +0200 Subject: [Ns-developers] wimax new patch In-Reply-To: <49997.217.128.71.243.1251477759.squirrel@imap-sop.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> <4A97AEBB.8080807@sophia.inria.fr> <4A97EE90.7010500@sophia.inria.fr> <49997.217.128.71.243.1251477759.squirrel@imap-sop.inria.fr> Message-ID: <4A9F8930.3050201@sophia.inria.fr> Faker, Please find attached a new patch providing default SNR traces for simple-ofdm-phy as well as a default MPEG4 trace file for the trace-based-application. Theses traces are provided as C++ header files to avoid path problems. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/7008525e/patch-0001.ksh From amine.ismail at sophia.inria.fr Thu Sep 3 03:22:43 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 03 Sep 2009 12:22:43 +0200 Subject: [Ns-developers] wimax new patch In-Reply-To: <4A9F8930.3050201@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> <4A97AEBB.8080807@sophia.inria.fr> <4A97EE90.7010500@sophia.inria.fr> <49997.217.128.71.243.1251477759.squirrel@imap-sop.inria.fr> <4A9F8930.3050201@sophia.inria.fr> Message-ID: <4A9F98F3.1040403@sophia.inria.fr> Faker, Please find attached a new patch with the correct coding style Ismail Amine wrote: > Faker, > > Please find attached a new patch providing default SNR traces for > simple-ofdm-phy as well as a default MPEG4 trace file for the > trace-based-application. Theses traces are provided as C++ header > files to avoid path problems. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wimaxpatch Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/0b60e8e0/wimaxpatch-0001.ksh From faker.moatamri at sophia.inria.fr Thu Sep 3 04:21:24 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 03 Sep 2009 13:21:24 +0200 Subject: [Ns-developers] wimax new patch In-Reply-To: <4A9F98F3.1040403@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> <4A97AEBB.8080807@sophia.inria.fr> <4A97EE90.7010500@sophia.inria.fr> <49997.217.128.71.243.1251477759.squirrel@imap-sop.inria.fr> <4A9F8930.3050201@sophia.inria.fr> <4A9F98F3.1040403@sophia.inria.fr> Message-ID: <4A9FA6B4.9040203@sophia.inria.fr> Ismail Amine wrote: > Faker, > > Please find attached a new patch with the correct coding style > Ok thanks, while building I got this error: ../src/devices/wimax/snr-to-block-error-rate-manager.cc:25:28: error: default-traces.h: No such file or directory can you please send me the traces needed? Thanks From amine.ismail at sophia.inria.fr Thu Sep 3 04:45:55 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 03 Sep 2009 13:45:55 +0200 Subject: [Ns-developers] wimax new patch In-Reply-To: <4A9FA6B4.9040203@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> <4A97AEBB.8080807@sophia.inria.fr> <4A97EE90.7010500@sophia.inria.fr> <49997.217.128.71.243.1251477759.squirrel@imap-sop.inria.fr> <4A9F8930.3050201@sophia.inria.fr> <4A9F98F3.1040403@sophia.inria.fr> <4A9FA6B4.9040203@sophia.inria.fr> Message-ID: <4A9FAC73.8050906@sophia.inria.fr> Faker Moatamri wrote: > Ismail Amine wrote: >> Faker, >> >> Please find attached a new patch with the correct coding style >> > Ok thanks, while building I got this error: > ../src/devices/wimax/snr-to-block-error-rate-manager.cc:25:28: error: > default-traces.h: No such file or directory > can you please send me the traces needed? > Thanks Hi Faker Please find attached these 3 files. copy deafult-traces and AUTHORS in src/devices/wimax and copy default-trace.h in /src/applications/trace-based-streamer Thanks -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AUTHORS Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/37117d55/AUTHORS-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: default-traces.h Type: text/x-chdr Size: 90900 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/37117d55/default-traces-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: default-trace.h Type: text/x-chdr Size: 1236 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/37117d55/default-trace-0001.bin From mathieu.lacage at sophia.inria.fr Thu Sep 3 06:17:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 03 Sep 2009 06:17:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200909031317.n83DHngv016565@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/92 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From faker.moatamri at sophia.inria.fr Thu Sep 3 07:08:35 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 03 Sep 2009 16:08:35 +0200 Subject: [Ns-developers] WiMAX module release and review Message-ID: <4A9FCDE3.3000700@sophia.inria.fr> Hi all, WiMAX module has been developed and was under development for more than 2 years now and it's high time to release it and to make it available to all NS-3 community. To reach that aim, we have been through a lot of modifications and enhancements to meet the NS-3 quality standards. We also put a time schedule for the integration of WiMAX module to the next NS-3 release (expected at the end of september), here is a small reminder with the results: - Monday August 17th: feature/Dev freeze, review and merge patches, testing and debugging ==> done on time - Thursday August 20th: Enhancement of the code to meet NS-3 standard ==> done on time - Wednesday August 26th: Merge with the latest version of ns-3-dev and testing ==> done on time - Tuesday September 1st: Submission of the proposed Wimax patch for review ==> done on Thursday, September 3rd I wish to thank all those who participated in the WiMAX module and helped me to make this release available with almost no delay with respect to our time schedule. As of today, the WiMAX module is integrated with ns-3-dev revision 4750:7dd4ad5ac045 and we are open to your comments and suggestions. In order to make the module available to all the community, we added three methods of getting the module: - Use mercurial repository: http://code.nsnam.org/fmoatamr/ns-3-wimax-release - Using Rietveld review tool: http://codereview.appspot.com/115051 - Using the attached patch which was made based on revision 4750:7dd4ad5ac045 of ns-3-dev main tree Please feel free to download the patch/code, to test it and to give us your feedback about it. You can also use Rietveld link above to review the code and put comments on it. Thanks Best regards Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: wimaxNs3.patch Type: text/x-patch Size: 995770 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/9462a3b5/wimaxNs3-0001.bin From mk.banchi at gmail.com Thu Sep 3 11:08:23 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 3 Sep 2009 20:08:23 +0200 Subject: [Ns-developers] Review block ack patch #1 In-Reply-To: <1251995493.11604.0.camel@diese.inria.fr> References: <1251809640.3332.1.camel@diese.inria.fr> <1251810626.3332.4.camel@diese.inria.fr> <62E0ECF0-BAAC-4B12-9682-05AE71283883@gmail.com> <1251995493.11604.0.camel@diese.inria.fr> Message-ID: <81F05D19-4808-4E91-9DB3-6190FDF5823F@gmail.com> Il giorno 03/set/09, alle ore 18:31, Mathieu Lacage ha scritto: > so, you don't actually implement block ack support here ? i.e., the > MacLow class does not appear to be using this extra enum value, > right ? > > I know what you want to say, but i do this in order to have very isolated and little commits...if you want to avoid unused (for now) part of code in ns-3-dev, i must create a bigger patch that adds a lot of functionalities and i think this is not correct. I also suggested to merge block ack header because it's impossible to implement part of block ack in MacLow without the use of them, so i suggest to start with code portions that don't use those headers. Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090903/f095a3d1/smime.bin From mathieu.lacage at sophia.inria.fr Fri Sep 4 08:47:57 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 04 Sep 2009 08:47:57 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200909041547.n84Flvxh026621@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/146 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The web-page 'force build' button was pressed by 'try it': Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_2 shell_3 shell_4 shell_5 shell_7 shell_8 shell_9 shell_11 shell_12 shell_13 sincerely, -The Buildbot From tomh at tomh.org Sat Sep 5 16:41:49 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 05 Sep 2009 16:41:49 -0700 Subject: [Ns-developers] Spelling for the manual In-Reply-To: <20090902171800.3c0acf3d.buchner.johannes@gmx.at> References: <20090902171800.3c0acf3d.buchner.johannes@gmx.at> Message-ID: <4AA2F73D.2010709@tomh.org> Johannes Buchner wrote: > Hi! > > I ran ispell over the manual after I saw a typo, so here is a patch > that fixes some spelling mistakes. Please apply. > > Best regards, > Johannes > Johannes, I applied your patch yesterday-- thanks for the corrections. - Tom From tomh at tomh.org Sat Sep 5 16:45:02 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 05 Sep 2009 16:45:02 -0700 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <20090819122000.GC15935@clipper.ens.fr> References: <20090819122000.GC15935@clipper.ens.fr> Message-ID: <4AA2F7FE.5070609@tomh.org> Guillaume Seguin wrote: > Some benchmarks I made showed a 15% speedup of the global routing table > initialization by not recomputing the NodeList::End () at every iteration in the > GlobalRouteManagerImpl code. May I push this patch to ns-3-dev ? Guillaume, I went ahead and pushed this patch, since I don't know if/when it would be otherwise solved by improving NodeList::End(). If someone wants to file a bug on NodeList::End(), feel free. Thanks, Tom From mathieu.lacage at sophia.inria.fr Mon Sep 7 03:58:13 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 03:58:13 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200909071058.n87AwDYR009992@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/151 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The web-page 'force build' button was pressed by 'try it': Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_4 shell_5 shell_11 shell_12 shell_13 sincerely, -The Buildbot From vincent at clarinet.u-strasbg.fr Mon Sep 7 07:23:49 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Mon, 07 Sep 2009 16:23:49 +0200 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <4A9639F7.8060805@clarinet.u-strasbg.fr> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A850F97.5020505@clarinet.u-strasbg.fr> <4A9639F7.8060805@clarinet.u-strasbg.fr> Message-ID: <4AA51775.3010109@clarinet.u-strasbg.fr> Seems like nobody against it. I will commit this patch tomorrow. Sebastien Vincent a ?crit : > Hi, > > I modified patch (http://www.nsnam.org/bugzilla/attachment.cgi?id=570) > to just use TracedCallback (no typedef to ListCallback) in > *-net-device files. > > Comments about this ? Is it OK to apply ? > > Regards, > -- > Sebastien > > Sebastien Vincent a ?crit : >> Tom Henderson a ?crit : >>> Mathieu Lacage wrote: >>>> On Thu, 2009-08-06 at 15:50 -0600, Tom Henderson wrote: >>>> >>>>>>> 1) use of TracedCallback? >>>>>>> Another option is to use a TracedCallback here, which some other >>>>>>> developers have recommended in the past to use when there needs >>>>>>> to be a list of callbacks. >>>>>>> >>>>>>> I don't have a strong opinion but this question keeps popping up >>>>>>> (also in Qasim's conntrack code) so I think we should clarify >>>>>>> whether TracedCallback should also be used in non-tracing >>>>>>> scenarios whenever you >>>>>>> want a std::list of callbacks, or whether we want another >>>>>>> general CallbackList of some sort that is not used by tracing code. >>>>>> I think that all you would need to make TracedCallback generic is >>>>>> change >>>>>> its name to something which does not include 'Trace'. i.e., its >>>>>> API and >>>>>> implementation has no dependency on the tracing code. >>>>> Maybe what would be best is to add something like the CallbackList >>>>> suggested but allow user to optionally specify order or priority of >>>>> callbacks-- if no priority is specified, they all get priority 0 >>>>> and it >>>>> behaves like TracedCallback. >>>> >>>> It's not clear to me what this priority would be used for. Do you >>>> have a >>>> specific usecase in mind ? >>> >>> iptables (chains of ordered rules) >>> >>> If not, I would support simply renaming >>>> TracedCallback to NotifierCallback or something similar (better >>>> suggestions for a name would be welcome) and typedef >>>> NotifierCallback to >>>> TracedCallback to avoid changing our existing codebase. >>> >>> I don't care strongly; ListCallback conveys the list semantics. >>> >>>> >>>>>>> 2) should we report link change, or link up? >>>>>>> The method name is not really suggestive of how the callback >>>>>>> works, which does not call when the link changes in all cases >>>>>>> but only when the >>>>>>> link goes to up. So, I would suggest either "AddLinkUpCallback" >>>>>>> or "SetLinkChangeCallback" with an extra argument such as an >>>>>>> enum for Up or >>>>>>> Down. >>>>>> The current implementation reports link change events, not link up >>>>>> events. i.e., see src/devices/wifi/wifi-net-devices.cc. The >>>>>> current API >>>>>> documentation in src/node/net-device.h should be improved instead of >>>>>> changing the method name I think. >>>>> Only WifiNetDevice reports all link changes, but you can't tell >>>>> from the >>>>> callback what type of event it was. The other devices >>>>> (PointToPoint, Csma, >>>> >>>> IsLinkUp is expected to be used from within the notification >>>> callback to >>>> query the state of the link. That was the original intend of the >>>> device >>>> API design. >>>> >>>>> Emu) just call it upon going up, perhaps because they can't go >>>>> down (it is >>>>> really only used at node startup time). >>>> >>>> Yes, none of them can go down which is why they never report link down >>>> events. >>>> >>>> Anyway, to summarize, I see no real need to change this API since it >>>> provides the needed functionality. What is needed is improving the >>>> doxygen which does not align with the intend of the original design. >>> >>> Can you clarify-- are you objecting to AddLinkChangeCallback as >>> Sebastien suggested, or changing other aspects as I later suggested >>> (such as changing the name or the arguments of the callback)? >>> >>> I am OK with what you suggest about using the API as you originally >>> intended with IsLinkUp(), and fixing the doxygen, but it seems like >>> Sebastien has a valid use case to make this a TracedCallback. >>> >> >> >> I made a small update on the patch on bugzilla >> (http://www.nsnam.org/bugzilla/show_bug.cgi?id=653) to use >> ListCallback (typedef from TracedCallback) in NetDevice. >> >> Regards, >> -- >> Sebastien >> >> >>>> >>>>>>> I think others have raised the question "can I put a NetDevice >>>>>>> into down >>>>>>> state?" and presently the answer is no, but in practice, IFF_UP >>>>>>> flag of a netdevice is settable, and it seems like we might want >>>>>>> to add the capability to configure an interface to down state, >>>>>>> which would trigger upcalls to both Ipv4 and Ipv6 stacks (and to >>>>>>> the routing protocols). >>>>>> What would be the expected semantics of that flag exactly ? Would >>>>>> you >>>>>> expect the NetDevice subclasses to honor calling SetIfDown by >>>>>> ignoring >>>>>> packets being passed down with NetDevice::Send* ? >>>>>> >>>>> Yes. I would try to match it to what happens in a real system when >>>>> "ifconfig eth0 down" is called. Note that this typically will >>>>> trigger >>>>> upcalls or netlink notifications, which cause the upper layer to >>>>> refrain >>>>> from sending packets down to it when it is in a down state. >>>> >>>> I think that it would be nice if adding such a flag would not require >>>> adding extra send/receive logic to net device implementations but I >>>> could live with it. >>>> >>> I think the burden here will be requiring netdevice users to >>> register for the link change callback and process it; I don't think >>> adding the extra NetDevice logic (shunt packets to a drop trace if >>> the device is down) will be too difficult. >>> >>> Tom >>> >> >> > > From mathieu.lacage at sophia.inria.fr Mon Sep 7 17:22:47 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 17:22:47 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200909080022.n880Ml8m015467@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/151 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_17 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Sep 7 17:44:17 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 17:44:17 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200909080044.n880iHoi015488@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/139 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_17 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Sep 7 18:06:47 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 18:06:47 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200909080106.n8816lcF015508@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/145 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_17 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Sep 7 18:33:07 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 18:33:07 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200909080133.n881X7RJ015532@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/138 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_17 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Sep 7 18:54:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 18:54:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.3.2 Message-ID: <200909080154.n881snwl015553@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.3.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.3.2/builds/133 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_17 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Sep 7 19:16:08 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 07 Sep 2009 19:16:08 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200909080216.n882G8JP015574@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/150 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_17 sincerely, -The Buildbot From vincent at clarinet.u-strasbg.fr Mon Sep 7 22:20:20 2009 From: vincent at clarinet.u-strasbg.fr (=?ISO-8859-1?Q?S=E9bastien_Vincent?=) Date: Tue, 08 Sep 2009 07:20:20 +0200 Subject: [Ns-developers] IPv6 longest prefix match and metrics In-Reply-To: <4A9CD4CA.4040103@clarinet.u-strasbg.fr> References: <4A9CD4CA.4040103@clarinet.u-strasbg.fr> Message-ID: <4AA5E994.6080302@clarinet.u-strasbg.fr> Hi all, IPv6 longest prefix support is now in ns-3-dev. Note: when we have a two (or more) IPv6 prefixes on a link, before this patch the default route was the first added (i.e. first prefix information option in RA). Now as (for the moment) all IPv6 default routes have the same metric (0), default route choosen with longest prefix algorithm will be the last added. Regards, -- Seb Sebastien Vincent a ?crit : > Hi, > > I see that patch from Antti Makela that add metrics and longest prefix > match for IPv4 static routing has been merged to ns-3-dev. I will try > to find some time this week to add its IPv6 counterpart. > > Regards, > -- > Sebastien Vincent > From vincent at clarinet.u-strasbg.fr Mon Sep 7 22:24:54 2009 From: vincent at clarinet.u-strasbg.fr (=?ISO-8859-1?Q?S=E9bastien_Vincent?=) Date: Tue, 08 Sep 2009 07:24:54 +0200 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <4AA51775.3010109@clarinet.u-strasbg.fr> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A850F97.5020505@clarinet.u-strasbg.fr> <4A9639F7.8060805@clarinet.u-strasbg.fr> <4AA51775.3010109@clarinet.u-strasbg.fr> Message-ID: <4AA5EAA6.4080705@clarinet.u-strasbg.fr> Hi, Patch applied. Note for Wimax developers, here a patch against ns-3-wimax-release for this API change (if you want to hg pull / merge with ns-3-dev): diff -r 89e99e9aac52 src/devices/wimax/wimax-net-device.cc --- a/src/devices/wimax/wimax-net-device.cc Thu Sep 03 14:53:12 2009 +0200 +++ b/src/devices/wimax/wimax-net-device.cc Tue Sep 08 07:18:57 2009 +0200 @@ -201,9 +201,9 @@ } void -WimaxNetDevice::SetLinkChangeCallback (Callback callback) +WimaxNetDevice::AddLinkChangeCallback (Callback callback) { - m_linkChange = callback; + m_linkChanges.ConnectWithoutContext (callback); } bool diff -r 89e99e9aac52 src/devices/wimax/wimax-net-device.h --- a/src/devices/wimax/wimax-net-device.h Thu Sep 03 14:53:12 2009 +0200 +++ b/src/devices/wimax/wimax-net-device.h Tue Sep 08 07:18:57 2009 +0200 @@ -173,7 +173,7 @@ virtual bool IsLinkUp (void) const; virtual void - SetLinkChangeCallback (Callback callback); + AddLinkChangeCallback (Callback callback); virtual bool IsBroadcast (void) const; virtual Address @@ -244,7 +244,7 @@ uint32_t m_ifIndex; std::string m_name; bool m_linkUp; - Callback m_linkChange; + TracedCallback<> m_linkChanges; uint32_t m_maxMsduSize; mutable uint16_t m_mtu; Regards, -- Sebastien Sebastien Vincent a ?crit : > Seems like nobody against it. I will commit this patch tomorrow. > > Sebastien Vincent a ?crit : >> Hi, >> >> I modified patch >> (http://www.nsnam.org/bugzilla/attachment.cgi?id=570) to just use >> TracedCallback (no typedef to ListCallback) in *-net-device files. >> >> Comments about this ? Is it OK to apply ? >> >> Regards, >> -- >> Sebastien >> >> Sebastien Vincent a ?crit : >>> Tom Henderson a ?crit : >>>> Mathieu Lacage wrote: >>>>> On Thu, 2009-08-06 at 15:50 -0600, Tom Henderson wrote: >>>>> >>>>>>>> 1) use of TracedCallback? >>>>>>>> Another option is to use a TracedCallback here, which some >>>>>>>> other developers have recommended in the past to use when there >>>>>>>> needs to be a list of callbacks. >>>>>>>> >>>>>>>> I don't have a strong opinion but this question keeps popping >>>>>>>> up (also in Qasim's conntrack code) so I think we should >>>>>>>> clarify whether TracedCallback should also be used in >>>>>>>> non-tracing scenarios whenever you >>>>>>>> want a std::list of callbacks, or whether we want another >>>>>>>> general CallbackList of some sort that is not used by tracing >>>>>>>> code. >>>>>>> I think that all you would need to make TracedCallback generic >>>>>>> is change >>>>>>> its name to something which does not include 'Trace'. i.e., its >>>>>>> API and >>>>>>> implementation has no dependency on the tracing code. >>>>>> Maybe what would be best is to add something like the CallbackList >>>>>> suggested but allow user to optionally specify order or priority of >>>>>> callbacks-- if no priority is specified, they all get priority 0 >>>>>> and it >>>>>> behaves like TracedCallback. >>>>> >>>>> It's not clear to me what this priority would be used for. Do you >>>>> have a >>>>> specific usecase in mind ? >>>> >>>> iptables (chains of ordered rules) >>>> >>>> If not, I would support simply renaming >>>>> TracedCallback to NotifierCallback or something similar (better >>>>> suggestions for a name would be welcome) and typedef >>>>> NotifierCallback to >>>>> TracedCallback to avoid changing our existing codebase. >>>> >>>> I don't care strongly; ListCallback conveys the list semantics. >>>> >>>>> >>>>>>>> 2) should we report link change, or link up? >>>>>>>> The method name is not really suggestive of how the callback >>>>>>>> works, which does not call when the link changes in all cases >>>>>>>> but only when the >>>>>>>> link goes to up. So, I would suggest either >>>>>>>> "AddLinkUpCallback" or "SetLinkChangeCallback" with an extra >>>>>>>> argument such as an enum for Up or >>>>>>>> Down. >>>>>>> The current implementation reports link change events, not link up >>>>>>> events. i.e., see src/devices/wifi/wifi-net-devices.cc. The >>>>>>> current API >>>>>>> documentation in src/node/net-device.h should be improved >>>>>>> instead of >>>>>>> changing the method name I think. >>>>>> Only WifiNetDevice reports all link changes, but you can't tell >>>>>> from the >>>>>> callback what type of event it was. The other devices >>>>>> (PointToPoint, Csma, >>>>> >>>>> IsLinkUp is expected to be used from within the notification >>>>> callback to >>>>> query the state of the link. That was the original intend of the >>>>> device >>>>> API design. >>>>> >>>>>> Emu) just call it upon going up, perhaps because they can't go >>>>>> down (it is >>>>>> really only used at node startup time). >>>>> >>>>> Yes, none of them can go down which is why they never report link >>>>> down >>>>> events. >>>>> >>>>> Anyway, to summarize, I see no real need to change this API since it >>>>> provides the needed functionality. What is needed is improving the >>>>> doxygen which does not align with the intend of the original design. >>>> >>>> Can you clarify-- are you objecting to AddLinkChangeCallback as >>>> Sebastien suggested, or changing other aspects as I later suggested >>>> (such as changing the name or the arguments of the callback)? >>>> >>>> I am OK with what you suggest about using the API as you originally >>>> intended with IsLinkUp(), and fixing the doxygen, but it seems like >>>> Sebastien has a valid use case to make this a TracedCallback. >>>> >>> >>> >>> I made a small update on the patch on bugzilla >>> (http://www.nsnam.org/bugzilla/show_bug.cgi?id=653) to use >>> ListCallback (typedef from TracedCallback) in NetDevice. >>> >>> Regards, >>> -- >>> Sebastien >>> >>> >>>>> >>>>>>>> I think others have raised the question "can I put a NetDevice >>>>>>>> into down >>>>>>>> state?" and presently the answer is no, but in practice, IFF_UP >>>>>>>> flag of a netdevice is settable, and it seems like we might >>>>>>>> want to add the capability to configure an interface to down >>>>>>>> state, which would trigger upcalls to both Ipv4 and Ipv6 stacks >>>>>>>> (and to the routing protocols). >>>>>>> What would be the expected semantics of that flag exactly ? >>>>>>> Would you >>>>>>> expect the NetDevice subclasses to honor calling SetIfDown by >>>>>>> ignoring >>>>>>> packets being passed down with NetDevice::Send* ? >>>>>>> >>>>>> Yes. I would try to match it to what happens in a real system when >>>>>> "ifconfig eth0 down" is called. Note that this typically will >>>>>> trigger >>>>>> upcalls or netlink notifications, which cause the upper layer to >>>>>> refrain >>>>>> from sending packets down to it when it is in a down state. >>>>> >>>>> I think that it would be nice if adding such a flag would not require >>>>> adding extra send/receive logic to net device implementations but I >>>>> could live with it. >>>>> >>>> I think the burden here will be requiring netdevice users to >>>> register for the link change callback and process it; I don't think >>>> adding the extra NetDevice logic (shunt packets to a drop trace if >>>> the device is down) will be too difficult. >>>> >>>> Tom >>>> >>> >>> >> >> > > From tomh at tomh.org Mon Sep 7 22:40:07 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 07 Sep 2009 22:40:07 -0700 Subject: [Ns-developers] Testing Framework -- Status and Sneak Peek [long] In-Reply-To: References: Message-ID: <4AA5EE37.1050104@tomh.org> craigdo at ee.washington.edu wrote: > I've put together a repository with the current testing framework and demo > code in it. To try it out: > > hg clone http://code.nsnam.org/ns-3-allinone ns-3-allinone-testing > cd ns-3-allinone-testing > ./download.py --ns3-branch=craigdo/ns-3-testing > ./build.py > cd ns-3-testing > ./waf --check > ./waf --regression > ./test.py Are there any further comments on Craig's test framework, or can we start to check it in? For reference, the original post that this message replies to is at: http://mailman.isi.edu/pipermail/ns-developers/2009-August/006370.html New files: ---------- test.py utils/test-runner.cc src/common/pcap-file.cc src/common/pcap-file.h src/common/pcap-file-test-suite.cc src/core/names-test-suite.cc src/core/rng-test-suite.cc src/test/ns3tcp/ns3tcp-cwnd-test-suite.cc src/test/ns3tcp/ns3tcp.h src/test/ns3tcp/ns3tcp-interop-test-suite.cc src/test/ns3wifi/ns3wifi.h src/test/ns3wifi/ns3wifi/propagation-loss-models-test-suite.cc Changed files: -------------- src/core/test.h src/core/test.cc New documentation: ----------------- doc/testing (texinfo document specific to testing; a preview of this is temporarily provided here:) http://www.nsnam.org/temp/testing/testing.pdf (PDF) http://www.nsnam.org/temp/testing/testing.html (html) New API (for test.py): ---------------------- Usage: test.py [options] Options: -h, --help show this help message and exit -c KIND, --constrain=KIND constrain the test-runner by kind of test -e EXAMPLE, --example=EXAMPLE specify a single example to run -k, --kinds print the kinds of tests available -l, --list print the list of known tests -n, --nowaf do not run waf before starting testing -s TEST-SUITE, --suite=TEST-SUITE specify a single test suite to run -v, --verbose print progress and informational messages -w HTML-FILE, --web=HTML-FILE, --html=HTML-FILE write detailed test results into HTML-FILE.html -t TEXT-FILE, --text=TEXT-FILE write detailed test results into TEXT-FILE.txt In addition, we would try to phase out the existing reference traces directory, or only use it as needed rather than by default. Open issues: ----------- 1) various revision/alignment of buildbot and regression test infrastructure 2) A few cleanup XXX issues in test.py 3) Translating some old-style test cases to the new TestSuite/TestCase structure. 4) Modularity > "As we get more and more tests up, and especially as new system tests are written, the ns-3 code is going to > balloon. We need to be able to split up the build process to build ns-3 > module code in each src directory, ns-3 test code in each src directory. We > need to be able to separately link ns-3 module and script code without > including the test stuff. We also need to be able to link a test runner > with the module code and the test code. I don't see how to do this right > now without major waf surgery. The concepts of source directory name, > module name, library name, number of header files and final executable > content seem to be very entangled. I made a half-hearted attempt to try and > figure this out, but got tired of waf fairly quickly. This isn't a huge > problem yet, but will be as more tests are introduced." > 5) Configuration cache The issues of accessing the configuration cache are not completely settled. > Right now test.py still looks directly at the waf configuration cache. This > should probably be changed such that waf can output a list of the needed > configuration items. I don't think this is a big deal, and haven't > addressed it yet. Right now, test.py does not use waf at all to run its > tests. I think eventually we will have enough test programs that it makes > sense not to run through waf so this should remain. The change needed is to > teach waf to dump "interesting information." > 6) a mode for verbose tracing and comparison (feature request) > What about Mathieu's comment recently about having a mode that dumps a > lot of trace locally (without downloading saved regression traces) for more > extensive regression testing before a checkin? > > Answer: There aren't any saved regression traces in the sense that we use > that term now.... but eventually I > would think it would be good to add a flag that is passed down to the test > suite via test.py > 7) Factoring out chi-squared testing > 11) Mathieu remarked early on that it would be nice to factor out the > chi-squared testing tools from within the random number tests, so they could > be used elsewhere. n.b. this was proposed in the below message back in May: http://mailman.isi.edu/pipermail/ns-developers/2009-May/005866.html > > Answer: The interesting thing about the chi-squared tests is that they are > trivial to implement, but difficult to really understand. If you look in > src/core/rng-test-suite.cc, you will find that the complete chi-squared test > including creating the histos, filling them and doing the test is only about > 20 lines of code. The hard thing to understand is why the numbers are what > they are and those numbers would have to be provided to a chi-square > function. I think a well-documented example with lots of words about > choosing the magic numbers might be just as good. > > Perhaps this starts getting more into developing a statistics toolkit more > than a testing toolkit. > 8) factoring out GSL, or using R-project instead or in addition > Can we avoid baking in a GSL dependency in case we want to rewrite > histogram or chi-squared routines ourselves in the future? > > Answer: Yes. I don't really relish the idea of writing cumulative > distribution functions for various distributions, though. GSL makes > statistical tests so much easier to deal with that I think we should really > begin to use it more. > > We could try and write a porting layer in between ns-3 and GSL to make it > easier to swap in other libraries, but I'm not sure we could get it even > close to right unless we knew what those libraries were. > 9) getting lcov reporting to work again; try to make it more explicit to developers whether the code coverage is improving or decreasing over time. Some of the above open issues are cleanup; some involve documentation or are longer term issues (e.g. modularity of build system). I don't think that any of them really should block the merge of this testing framework at this point, since I'm eager to get people to start contributing more tests. Maybe the chi-squared documentation/example and revising samples/main-test.cc might be at the top of my list to fix now. I'm not sure about spending time on a porting layer on top of GSL right now. Any other thoughts about moving forward with this framework? Tom From tomh at tomh.org Mon Sep 7 22:56:39 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 07 Sep 2009 22:56:39 -0700 Subject: [Ns-developers] next ns-3 release In-Reply-To: <4A8025E1.7000303@tomh.org> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A7FEB51.2050102@sophia.inria.fr> <4A8025E1.7000303@tomh.org> Message-ID: <4AA5F217.2000407@tomh.org> Tom Henderson wrote: > Faker Moatamri wrote: >> Hi all, >> In order to add features to NS-3, we would like to merge the wimax >> module to the next NS-3 release. > > We haven't set a date for the next release, although if we keep roughly > to our current quarterly schedule, it would be around the beginning of > October. I put a release page template at the below page, with a > provisional date of October 7. > > http://www.nsnam.org/wiki/index.php/Ns-3.6 > > Craig agreed to be release manager again, so here is an initial page and > he can start to manage the merge process. Please start to coordinate > with Craig if you want to merge new features to ns-3.6. > > - Tom It has been about a month since I posted the above note, and we seem to be in the following state: - we've merged the IPv6 code and several wifi extensions - we have a long list of modules that people seem to want to get into the next release: 1) 802.11s mesh 2) WiMAX models 3) test framework 4) NetAnim animator support 5) MPI-based distributed simulations 6) Nix-vector routing 7) PacketBB ? 8) Flow monitor ? (please remind me if I'm missing some) I don't think it is realistic to hold to an Oct. 7 date and try to merge all of the above. I also am leery of pushing back the release a month or more to try to get everything in, if it means we are continuing to distribute ns-3.5 as the latest release. It seems like we could do a few things at this point: - issue an ns-3.5.1 release that fixes FC 11 build and several other bug fixes since the July release, and delay ns-3.6 - try to create an ns-3.6 release now with what we have, and start to add the above items to ns-3.7 - select a subset of the "ready-to-go" items in the above and hold to the original plan for early October, and defer the rest. (updating ns-3.5 may be orthogonal to what we decide to do with ns-3.6) Please let Craig know (on the list, preferably) if you want to try to merge new code in the near future, so we can see better what is the status of the above work. Thanks, Tom From mathieu.lacage at sophia.inria.fr Tue Sep 8 00:24:10 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 09:24:10 +0200 Subject: [Ns-developers] next ns-3 release In-Reply-To: <4AA5F217.2000407@tomh.org> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A7FEB51.2050102@sophia.inria.fr> <4A8025E1.7000303@tomh.org> <4AA5F217.2000407@tomh.org> Message-ID: <1252394650.25311.9.camel@diese.inria.fr> On Mon, 2009-09-07 at 22:56 -0700, Tom Henderson wrote: > - we've merged the IPv6 code and several wifi extensions > - we have a long list of modules that people seem to want to get into > the next release: > 1) 802.11s mesh > 2) WiMAX models > 3) test framework > 4) NetAnim animator support > 5) MPI-based distributed simulations > 6) Nix-vector routing > 7) PacketBB ? > 8) Flow monitor ? > (please remind me if I'm missing some) (there were some multithreaded simulator patches which floated around but I don't think they are ready) Because I have reviewed 1,2, and 3, I support merging these. I also believe that we should focus on doing a time-based release, not a feature-based release which means that, from my perspective, the other items should aim for merging _after_ ns-3.6-release-day. Ideally, they should be merged on ns-3.6-release-day+1 if they have been properly reviewed. > - select a subset of the "ready-to-go" items in the above and hold to > the original plan for early October, and defer the rest. I strongly support that. Alternatively, it would help if those who wish to merge code would send a reminder on the list about what they are proposing for merging, and where the relevant review patches are. Mathieu From mathieu.lacage at sophia.inria.fr Tue Sep 8 01:01:48 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 10:01:48 +0200 Subject: [Ns-developers] Testing Framework -- Status and Sneak Peek [long] In-Reply-To: <4AA5EE37.1050104@tomh.org> References: <4AA5EE37.1050104@tomh.org> Message-ID: <1252396908.25311.46.camel@diese.inria.fr> tom, craig, Details below but, to summarize: 1) +1 for merge now 2) I have one blocker for ns-3.6 release (not merging): making sure that we remove the classes Test and TestManager. On Mon, 2009-09-07 at 22:40 -0700, Tom Henderson wrote: > New documentation: > ----------------- > doc/testing (texinfo document specific to testing; a preview of this is > temporarily provided here:) > > http://www.nsnam.org/temp/testing/testing.pdf (PDF) > http://www.nsnam.org/temp/testing/testing.html (html) Nice, I had missed this originally. > 3) Translating some old-style test cases to the new TestSuite/TestCase > structure. I think that we should not ship ns-3.6 with both the old and the new test frameworks. This does not mean that it's a requirement before merging the new framework but I think that we should focus on cleaning up this stuff to avoid potential user confusion. i.e., the new code is duplicating the existing functionality from the Test/TestManager class. If the new classes are the way forward, we need to kill the old code and, no, we can't wait because if we wait, no one will ever do it and we will just accumulate more cruft. > 6) a mode for verbose tracing and comparison (feature request) > > > What about Mathieu's comment recently about having a mode that dumps a > > lot of trace locally (without downloading saved regression traces) for more > > extensive regression testing before a checkin? > > > > Answer: There aren't any saved regression traces in the sense that we use > > that term now.... but eventually I > > would think it would be good to add a flag that is passed down to the test > > suite via test.py If this is not implemented, I would like to see this filed as a bug and that bug being given a high priority at least for next release. > 8) factoring out GSL, or using R-project instead or in addition > > > Can we avoid baking in a GSL dependency in case we want to rewrite > > histogram or chi-squared routines ourselves in the future? > > > > Answer: Yes. I don't really relish the idea of writing cumulative > > distribution functions for various distributions, though. GSL makes > > statistical tests so much easier to deal with that I think we should > really > > begin to use it more. > > > > We could try and write a porting layer in between ns-3 and GSL to make it > > easier to swap in other libraries, but I'm not sure we could get it even > > close to right unless we knew what those libraries were. If this is not implemented, we need to decide if this is a long term goal, and, if it is, file a bug to keep track of this issue. > 9) getting lcov reporting to work again; try to make it more explicit to > developers whether the code coverage is improving or decreasing over time. lcov reporting does not work ? Is there a bug report about this ? > I don't think that any of them really should block the merge of this > testing framework at this point, since I'm eager to get people to start > contributing more tests. Maybe the chi-squared documentation/example > and revising samples/main-test.cc might be at the top of my list to fix > now. I'm not sure about spending time on a porting layer on top of GSL > right now. Any other thoughts about moving forward with this framework? The attached patch fixes a couple of build failures on my system, as well as makes sure that the build proceeds, even when gsl is not present. Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: build.patch Type: text/x-patch Size: 3284 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090908/505fce5c/build.bin From mathieu.lacage at sophia.inria.fr Tue Sep 8 01:08:14 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 10:08:14 +0200 Subject: [Ns-developers] Testing Framework -- Status and Sneak Peek [long] In-Reply-To: <1252396908.25311.46.camel@diese.inria.fr> References: <4AA5EE37.1050104@tomh.org> <1252396908.25311.46.camel@diese.inria.fr> Message-ID: <1252397295.25311.47.camel@diese.inria.fr> And another patch needed to complete build on 32bit machines. Mathieu On Tue, 2009-09-08 at 10:01 +0200, Mathieu Lacage wrote: > tom, craig, > > Details below but, to summarize: > 1) +1 for merge now > 2) I have one blocker for ns-3.6 release (not merging): making sure that > we remove the classes Test and TestManager. > > > On Mon, 2009-09-07 at 22:40 -0700, Tom Henderson wrote: > > > New documentation: > > ----------------- > > doc/testing (texinfo document specific to testing; a preview of this is > > temporarily provided here:) > > > > http://www.nsnam.org/temp/testing/testing.pdf (PDF) > > http://www.nsnam.org/temp/testing/testing.html (html) > > Nice, I had missed this originally. > > > 3) Translating some old-style test cases to the new TestSuite/TestCase > > structure. > > I think that we should not ship ns-3.6 with both the old and the new > test frameworks. This does not mean that it's a requirement before > merging the new framework but I think that we should focus on cleaning > up this stuff to avoid potential user confusion. i.e., the new code is > duplicating the existing functionality from the Test/TestManager class. > If the new classes are the way forward, we need to kill the old code > and, no, we can't wait because if we wait, no one will ever do it and we > will just accumulate more cruft. > > > 6) a mode for verbose tracing and comparison (feature request) > > > > > What about Mathieu's comment recently about having a mode that dumps a > > > lot of trace locally (without downloading saved regression traces) for more > > > extensive regression testing before a checkin? > > > > > > Answer: There aren't any saved regression traces in the sense that we use > > > that term now.... but eventually I > > > would think it would be good to add a flag that is passed down to the test > > > suite via test.py > > If this is not implemented, I would like to see this filed as a bug and > that bug being given a high priority at least for next release. > > > 8) factoring out GSL, or using R-project instead or in addition > > > > > Can we avoid baking in a GSL dependency in case we want to rewrite > > > histogram or chi-squared routines ourselves in the future? > > > > > > Answer: Yes. I don't really relish the idea of writing cumulative > > > distribution functions for various distributions, though. GSL makes > > > statistical tests so much easier to deal with that I think we should > > really > > > begin to use it more. > > > > > > We could try and write a porting layer in between ns-3 and GSL to make it > > > easier to swap in other libraries, but I'm not sure we could get it even > > > close to right unless we knew what those libraries were. > > If this is not implemented, we need to decide if this is a long term > goal, and, if it is, file a bug to keep track of this issue. > > > 9) getting lcov reporting to work again; try to make it more explicit to > > developers whether the code coverage is improving or decreasing over time. > > lcov reporting does not work ? Is there a bug report about this ? > > > I don't think that any of them really should block the merge of this > > testing framework at this point, since I'm eager to get people to start > > contributing more tests. Maybe the chi-squared documentation/example > > and revising samples/main-test.cc might be at the top of my list to fix > > now. I'm not sure about spending time on a porting layer on top of GSL > > right now. Any other thoughts about moving forward with this framework? > > The attached patch fixes a couple of build failures on my system, as > well as makes sure that the build proceeds, even when gsl is not > present. > > Mathieu > -------------- next part -------------- A non-text attachment was scrubbed... Name: tcp.patch Type: text/x-patch Size: 696 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090908/8ad34b8f/tcp.bin From amine.ismail at sophia.inria.fr Tue Sep 8 02:57:49 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 08 Sep 2009 11:57:49 +0200 Subject: [Ns-developers] LTE on ns-3 Message-ID: <4AA62A9D.9060108@sophia.inria.fr> Hi all, Is there some person working on an LTE module for ns-3? From gjcarneiro at gmail.com Tue Sep 8 03:34:00 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 8 Sep 2009 11:34:00 +0100 Subject: [Ns-developers] Proposing to merge FlowMonitor in ns-3-dev Message-ID: A reminder that I am still interested in merging FlowMonitor. The code I am working on is at: http://code.nsnam.org/gjc/ns-3-dev-flowmon/ Below a summary of the last email exchanges on the subject. Mathieu once commented that: > sorry for taking so long to look at this: I don't have many comments > other than that it is missing needed api documentation and that it's > looks pretty cool :) > > The histogram class probably should go in either src/contrib or > src/common directly. > > I will work on the documentation front. I also don't mind about moving the histogram class. Any other opinions on this issue? Tom said: > Hi Gustavo, I also looked at this yesterday and would like to propose to > get it merged this release cycle. I wonder whether there is common > functionality to what Qasim is working on for a conntracking module; maybe > he can review and comment. > I looked at NetFilter code but could not see, at least right away, what could be reused from connection tracking. However, this is mostly implementation detail and does not impact the API, so that it would still be possible to do it in the future, in case I am mistaken. Tom said also: > It seemed to me that we could move the core components of this to > src/common, and the ipv4-specific to internet-stack. > What do you mean by "core components"? All of the FlowMonitor core components, like classes FlowMonitor, FlowProbe, FlowClassifier, Histogram? Not just Histogram? But then the flow-monitor module disappears, dissolving into src/common and src/internet-stack, is that what you mean? Well, I guess I am OK, with it, although I was expecting a kind of "probation" period where a module proves its usefulness to the ns-3 users by spending some time in src/contrib. About this last issue, Mathieu said: > If you do this, we will need to improve the doxygen for these classes. > If they stay as-is without additional documentation, they should be > merged in src/contrib. > Well, I think it should be documented regardless. Next Tom also said: > You could keep it in src/contrib for now if you want to allow it to draw > comments for a while. > Summary of open issues: 1. Need more doxygen for FlowMonitor. I will work on this. 2. Need to approve the Ipv4L3Protocol traced source changes. I have received some comments, but no clear approval yet; 3. Decide whether to keep flow-monitor as a src/contrib module or dissolve it into src/common and src/internet-stack. Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From andreev at iitp.ru Tue Sep 8 04:07:04 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Tue, 08 Sep 2009 15:07:04 +0400 Subject: [Ns-developers] Merging 802.11s code Message-ID: Hi! The code of 802.11s is ready to merge and was reviewed by Mathieu and he gave us +1 on merging. Now we need one more +1 to merge (especially by Tom and Craig). Code repository is located at https://forge.iitp.ru/hgprojects/ns3dev Patch set at code review is located at http://codereview.appspot.com/88094 Regards, Kirill Andreev IITP RAS From monbauza at gmail.com Tue Sep 8 04:36:08 2009 From: monbauza at gmail.com (monbauza@gmail.com) Date: Tue, 08 Sep 2009 11:36:08 +0000 Subject: [Ns-developers] channel switching support for wifi Message-ID: <001636b2b3ff5642ad04730f5f6e@google.com> Reviewers: Mathieu Lacage, Message: Hi Mathieu, all, After almost a month (due to summer holidays and a lot of work :-), I have been able now to update the patch related to channel switching support for wifi. I have uploaded a new patch set with additions in dcf-manager-test (http://codereview.appspot.com/96109/show). Comments and suggestions are welcome. Thank you very much. Ramon. http://codereview.appspot.com/96109/diff/1/6 File src/devices/wifi/dcf-manager.cc (right): http://codereview.appspot.com/96109/diff/1/6#newcode626 Line 626: DcfManager::NotifySwitchingStartNow (Time duration) On 2009/08/19 08:19:12, Mathieu Lacage wrote: > I would like to see an associated test in dcf-manager-test.cc for this function > to exercise its many code paths. done. http://codereview.appspot.com/96109/diff/1/6#newcode633 Line 633: { On 2009/08/19 08:19:12, Mathieu Lacage wrote: > indent done. http://codereview.appspot.com/96109/diff/1/12 File src/devices/wifi/mac-low.cc (right): http://codereview.appspot.com/96109/diff/1/12#newcode297 Line 297: m_phyMacLowListener = new PhyMacLowListener (this); On 2009/08/19 08:19:12, Mathieu Lacage wrote: > delete in DoDispose ? Not before. done. http://codereview.appspot.com/96109/diff/1/13 File src/devices/wifi/mac-low.h (right): http://codereview.appspot.com/96109/diff/1/13#newcode284 Line 284: void SetupPhyMacLowListener (Ptr phy); On 2009/08/19 08:19:12, Mathieu Lacage wrote: > make this private done. http://codereview.appspot.com/96109/diff/1/17 File src/devices/wifi/yans-wifi-phy.cc (right): http://codereview.appspot.com/96109/diff/1/17#newcode355 Line 355: m_channelNumber = nch; On 2009/08/19 08:19:12, Mathieu Lacage wrote: > I am curious: do you ever use m_channelNumber anywhere ? it seems all you do in > this patchset is keep track of this number, but never use it to implement an > actual model of receiving packets on different channels ? Yes, m_channelNumber is used (through YansWifiPhy::GetChannelNumber) in YansWifiChannel::Send. http://codereview.appspot.com/96109/diff/1/17#newcode359 Line 359: * This function wouldn't be really needed because channel switching delay is On 2009/08/19 08:19:12, Mathieu Lacage wrote: > so, why is it needed ? removed. http://codereview.appspot.com/96109/diff/1/17#newcode412 Line 412: NS_LOG_DEBUG ("drop packet because of channel switching (power="<< On 2009/08/19 08:19:12, Mathieu Lacage wrote: > is this debug message really relevant ? I don't see how rx power is used here. This message allows tracking those packets received during a switching period (YansWifiPhy::m_channelSwitchDelay). Please review this at http://codereview.appspot.com/96109 Affected files: M examples/wifi-ap.cc M src/devices/wifi/dca-txop.cc M src/devices/wifi/dca-txop.h M src/devices/wifi/dcf-manager-test.cc M src/devices/wifi/dcf-manager.cc M src/devices/wifi/dcf-manager.h M src/devices/wifi/edca-txop-n.cc M src/devices/wifi/edca-txop-n.h M src/devices/wifi/interference-helper.cc M src/devices/wifi/interference-helper.h M src/devices/wifi/mac-low.cc M src/devices/wifi/mac-low.h M src/devices/wifi/wifi-phy-state-helper.cc M src/devices/wifi/wifi-phy-state-helper.h M src/devices/wifi/wifi-phy.h M src/devices/wifi/yans-wifi-phy.cc M src/devices/wifi/yans-wifi-phy.h From mathieu.lacage at sophia.inria.fr Tue Sep 8 04:48:51 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 13:48:51 +0200 Subject: [Ns-developers] channel switching support for wifi In-Reply-To: <001636b2b3ff5642ad04730f5f6e@google.com> References: <001636b2b3ff5642ad04730f5f6e@google.com> Message-ID: <1252410531.25311.49.camel@diese.inria.fr> On Tue, 2009-09-08 at 11:36 +0000, monbauza at gmail.com wrote: > http://codereview.appspot.com/96109/diff/1/17#newcode355 > Line 355: m_channelNumber = nch; > On 2009/08/19 08:19:12, Mathieu Lacage wrote: > > I am curious: do you ever use m_channelNumber anywhere ? it seems all > you do in > > this patchset is keep track of this number, but never use it to > implement an > > actual model of receiving packets on different channels ? > > Yes, m_channelNumber is used (through YansWifiPhy::GetChannelNumber) in > YansWifiChannel::Send. This patchset does not contain any changes to yans-wifi-channel.cc Mathieu From faker.moatamri at sophia.inria.fr Tue Sep 8 05:15:31 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 08 Sep 2009 14:15:31 +0200 Subject: [Ns-developers] WiMAX review request Message-ID: <4AA64AE3.4020809@sophia.inria.fr> Hi all, I would like to ask you kindly to review the WiMAX module code. The WiMAX module implements the 802.16 specification. Here is the list of new/changed files: New files: Added a new directories: src/devices/wimax src/applications/trace-based-streamer src/applications/udp-client-server Added new files: examples/wimax.cc examples/wimax-ipv4.cc examples/wimax-mulicast.cc examples/wimax-simple.cc src/helper/trace-based-streamer-helper.cc/h src/helper/udp-helper.cc/h src/helper/wimax-helper.cc/h Changed: src/common/pcap-writer.cc/h src/core/config.h Documentation: It can be found in src/devices/wimax/README, there is also the attached wimax.h file which will be finalized and added to the tree once finished. Compiling and building: Requirments: This module requires the presence of the *IT++ library*, under linux you can install it simply using yum/apt-get depending on your distribution. Without this library, the wimax code will be ignored and it will not be compiled. We plan to remove this dependency on IT++ for next release. Getting the code: - You can download the code from http://code.nsnam.org/iamine/ns-3-wimax-release/ , it is merged with the revision 4750 of ns-3-dev - You can use the attached patch and apply it on revision 4750 of ns-3-dev Compile and build: - You use the usual ./waf configure, you should have WiMAX module : Enabled to be sure that wimax will be compiled and built - ./waf to compile and build Testing: WiMAX module testing is based on 2 example scenarios that are used for regression testing. To enable the testing you compile with WIMAX_TEST flag: CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf You run the tests simply by running the examples: wimax-ipv4 wimax-multicast You can also specify the scheduling type using -s option: [-s scheduling_type] The scheduling type can be: - 0 for SCHED_TYPE_SIMPLE (default) - 1 for SCHED_TYPE_MBQOS - 2 for SCHED_TYPE_RTPS You should get ok as output of the tests. Reviewing the code: The code has been uploaded to the Rietveld reviewing tool: http://codereview.appspot.com/115051 You can review and put comments on the code. Thank you very much Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: wimaxNs3.patch Type: text/x-patch Size: 995770 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090908/67e293ec/wimaxNs3-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: wimax.h Type: text/x-chdr Size: 16297 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090908/67e293ec/wimax-0001.bin From monbauza at gmail.com Tue Sep 8 06:17:56 2009 From: monbauza at gmail.com (Ramon Bauza) Date: Tue, 8 Sep 2009 15:17:56 +0200 Subject: [Ns-developers] channel switching support for wifi In-Reply-To: <1252410531.25311.49.camel@diese.inria.fr> References: <001636b2b3ff5642ad04730f5f6e@google.com> <1252410531.25311.49.camel@diese.inria.fr> Message-ID: <63e322e20909080617t3f78a4dfv56674b6b0e8a4821@mail.gmail.com> 2009/9/8 Mathieu Lacage > On Tue, 2009-09-08 at 11:36 +0000, monbauza at gmail.com wrote: > > > http://codereview.appspot.com/96109/diff/1/17#newcode355 > > Line 355: m_channelNumber = nch; > > On 2009/08/19 08:19:12, Mathieu Lacage wrote: > > > I am curious: do you ever use m_channelNumber anywhere ? it seems all > > you do in > > > this patchset is keep track of this number, but never use it to > > implement an > > > actual model of receiving packets on different channels ? > > > > Yes, m_channelNumber is used (through YansWifiPhy::GetChannelNumber) in > > YansWifiChannel::Send. > > > This patchset does not contain any changes to yans-wifi-channel.cc > > Mathieu > > Changes to yans-wifi-channel.cc were done by Pavel Boyko in ( http://codereview.appspot.com/91057/show) some time ago. Those changes are already included in the current ns-3-dev branch. Should I also include them in the patch? Ramon From mathieu.lacage at sophia.inria.fr Tue Sep 8 06:21:35 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 15:21:35 +0200 Subject: [Ns-developers] channel switching support for wifi In-Reply-To: <63e322e20909080617t3f78a4dfv56674b6b0e8a4821@mail.gmail.com> References: <001636b2b3ff5642ad04730f5f6e@google.com> <1252410531.25311.49.camel@diese.inria.fr> <63e322e20909080617t3f78a4dfv56674b6b0e8a4821@mail.gmail.com> Message-ID: <1252416095.5372.2.camel@localhost.localdomain> On Tue, 2009-09-08 at 15:17 +0200, Ramon Bauza wrote: > Changes to yans-wifi-channel.cc were done by Pavel Boyko in > (http://codereview.appspot.com/91057/show) some time ago. Those > changes are already included in the current ns-3-dev branch. Should I > also include them in the patch? Ha, ok: I forgot about this change. Your patch looks good to me then. thanks a lot, Mathieu From monbauza at gmail.com Tue Sep 8 06:58:22 2009 From: monbauza at gmail.com (Ramon Bauza) Date: Tue, 8 Sep 2009 15:58:22 +0200 Subject: [Ns-developers] Multiple frequency channels supported in yans wifi channel and PHY In-Reply-To: <74fef6df0908190121q3e86318cte7efc7d9df4d3fd7@mail.gmail.com> References: <0016368e207e9f9f63046ed18276@google.com> <63e322e20907231022k1cba8c2ft8ae4807161cd6fdc@mail.gmail.com> <74fef6df0908190121q3e86318cte7efc7d9df4d3fd7@mail.gmail.com> Message-ID: <63e322e20909080658q7403c150ye7d122fec6334681@mail.gmail.com> 2009/8/19 Mathieu Lacage > On Thu, Jul 23, 2009 at 7:22 PM, Ramon Bauza wrote: > > > Once the patch has been reviewed, we have in mind to implement a > > ChannelSwitchingManager that will further extend the current multichannel > > support implementation. This ChannelSwitchingManager will be aggregated > to > > the NetDevice and will have, as an example, the following member > functions: > > Would it not be simpler to simply add these methods to WifiNetDevice ? > > > > > // Switch channel after current PHY transmission has been completed. > > DcaTxop/EdcaTxop queues are flushed. > > void SwitchChannel (uint16_t channelNumber); > > > > // Switch channel after current MAC transmission has been completed > > (rts/cts/data/ack). > > // DcaTxop/EdcaTxop queues are flushed. > > void SwitchChannelAfterMacTxon (uint16_t channelNumber); > > > > // Switch channel after all enqueued packets have been transmitted. > > void SwitchChannelAfterQueuesServed (uint16_t channelNumber); > > > > // Called before performing a channel switching. > > // Later on, the stored packets will be able to be enqueued and > transmited > > in any other channel. > > void StorePacketsForLaterTxon (void); > > > > I would like you to review the patch and provide us with your feedback > and > > comments. > > Mathieu > -- > Mathieu Lacage > Yes, it would be simpler. However, implementing a switching manager in a new class, independent from WifiNetDevice, would make the code more modular and would also allow users to implement new functionalities. For example, the user may want to store the packets that have not been able to be transmitted due to a channel switching. These packets may be transmitted later on the same channel they were initially scheduled on. In this case, it would be good to have a packet queue per each of the possible channels the netdevice can switch among, e.g. a netdevice switching among three different channels CH1, CH2 and CH3 would have three different packet queues in which packets may be stored for later transmission. Do you think it would be better to include all this in WifiNetDevice, or on the contrary, in a separate class, e.g. SwitchingManager? Ramon From mathieu.lacage at sophia.inria.fr Tue Sep 8 08:09:06 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 17:09:06 +0200 Subject: [Ns-developers] Multiple frequency channels supported in yans wifi channel and PHY In-Reply-To: <63e322e20909080658q7403c150ye7d122fec6334681@mail.gmail.com> References: <0016368e207e9f9f63046ed18276@google.com> <63e322e20907231022k1cba8c2ft8ae4807161cd6fdc@mail.gmail.com> <74fef6df0908190121q3e86318cte7efc7d9df4d3fd7@mail.gmail.com> <63e322e20909080658q7403c150ye7d122fec6334681@mail.gmail.com> Message-ID: <1252422546.25311.91.camel@diese.inria.fr> On Tue, 2009-09-08 at 15:58 +0200, Ramon Bauza wrote: > Yes, it would be simpler. However, implementing a switching manager in a new > class, independent from WifiNetDevice, would make the code more modular and > would also allow users to implement new functionalities. For example, the > user may want to store the packets that have not been able to be transmitted > due to a channel switching. These packets may be transmitted later on the > same channel they were initially scheduled on. In this case, it would be > good to have a packet queue per each of the possible channels the netdevice > can switch among, e.g. a netdevice switching among three different channels > CH1, CH2 and CH3 would have three different packet queues in which packets > may be stored for later transmission. Do you think it would be better to > include all this in WifiNetDevice, or on the contrary, in a separate class, > e.g. SwitchingManager? I don't really understand this: could you be more specific about what you have in mind with a per-channel packet queue ? When would you store packets in there ? When would you remove them ? regards, Mathieu From gjcarneiro at gmail.com Tue Sep 8 09:20:47 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 8 Sep 2009 17:20:47 +0100 Subject: [Ns-developers] ./waf --doxygen-no-build Message-ID: While documenting the flow monitor code, I have quickly become irritated with ./waf --doxygen because it waits for the build to finish before running doxygen, which can slow down doxygen when you are only trying to catch doxygen errors. So I added ./waf --doxygen-no-build in my tree, which runs doxygen before the build is finished. Any objections to adding this to ns-3-dev? -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From monbauza at gmail.com Tue Sep 8 09:28:37 2009 From: monbauza at gmail.com (Ramon Bauza) Date: Tue, 8 Sep 2009 18:28:37 +0200 Subject: [Ns-developers] Multiple frequency channels supported in yans wifi channel and PHY In-Reply-To: <1252422546.25311.91.camel@diese.inria.fr> References: <0016368e207e9f9f63046ed18276@google.com> <63e322e20907231022k1cba8c2ft8ae4807161cd6fdc@mail.gmail.com> <74fef6df0908190121q3e86318cte7efc7d9df4d3fd7@mail.gmail.com> <63e322e20909080658q7403c150ye7d122fec6334681@mail.gmail.com> <1252422546.25311.91.camel@diese.inria.fr> Message-ID: <63e322e20909080928u68090a43o471607cad4916781@mail.gmail.com> 2009/9/8 Mathieu Lacage > On Tue, 2009-09-08 at 15:58 +0200, Ramon Bauza wrote: > > > Yes, it would be simpler. However, implementing a switching manager in a > new > > class, independent from WifiNetDevice, would make the code more modular > and > > would also allow users to implement new functionalities. For example, the > > user may want to store the packets that have not been able to be > transmitted > > due to a channel switching. These packets may be transmitted later on the > > same channel they were initially scheduled on. In this case, it would be > > good to have a packet queue per each of the possible channels the > netdevice > > can switch among, e.g. a netdevice switching among three different > channels > > CH1, CH2 and CH3 would have three different packet queues in which > packets > > may be stored for later transmission. Do you think it would be better to > > include all this in WifiNetDevice, or on the contrary, in a separate > class, > > e.g. SwitchingManager? > > I don't really understand this: could you be more specific about what > you have in mind with a per-channel packet queue ? When would you store > packets in there ? When would you remove them ? > > regards, > Mathieu > > Sorry if i didn't make myself understood. Here, further details: - By a per-channel queue, I mean a WifiMacQueue (if dca is considered) or a set of WifiMacQueue (if edca is considered). These queues would store packets that were scheduled (enqueued in the netdevice) to be transmitted, but they were not transmitted because a channel switching occurred. By default, when a channel switching is performed, all enqueued packets in the dca/edca queues are removed. - Packets are stored in the per-channel queue when a channel switching is going to be performed and we don't want to lose the packets enqued in the netdevice dca/edca queues. Storing these packets in the per-channel queue/queues before switching, would allow us to later transmit them on the same channel or even on a different one. Assuming that a netdevice can switch among different channels, we may have a packet queue (or a set of queues, in edca) per channel. - Packets are removed from per-channel queues when they are re-enqueued in the netdevice dca/edca queues to be transmitted. Ramon From mathieu.lacage at sophia.inria.fr Tue Sep 8 11:49:37 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 08 Sep 2009 20:49:37 +0200 Subject: [Ns-developers] ./waf --doxygen-no-build In-Reply-To: References: Message-ID: <1252435777.2647.4.camel@localhost.localdomain> On Tue, 2009-09-08 at 17:20 +0100, Gustavo Carneiro wrote: > While documenting the flow monitor code, I have quickly become irritated > with ./waf --doxygen because it waits for the build to finish before running > doxygen, which can slow down doxygen when you are only trying to catch > doxygen errors. So I added ./waf --doxygen-no-build in my tree, which runs > doxygen before the build is finished. Any objections to adding this to > ns-3-dev? +1 Mathieu From tomh at tomh.org Tue Sep 8 22:22:43 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 08 Sep 2009 22:22:43 -0700 Subject: [Ns-developers] Testing Framework -- Status and Sneak Peek [long] In-Reply-To: <1252396908.25311.46.camel@diese.inria.fr> References: <4AA5EE37.1050104@tomh.org> <1252396908.25311.46.camel@diese.inria.fr> Message-ID: <4AA73BA3.80701@tomh.org> Mathieu Lacage wrote: > tom, craig, > > Details below but, to summarize: > 1) +1 for merge now > 2) I have one blocker for ns-3.6 release (not merging): making sure that > we remove the classes Test and TestManager. > > > On Mon, 2009-09-07 at 22:40 -0700, Tom Henderson wrote: > >> New documentation: >> ----------------- >> doc/testing (texinfo document specific to testing; a preview of this is >> temporarily provided here:) >> >> http://www.nsnam.org/temp/testing/testing.pdf (PDF) >> http://www.nsnam.org/temp/testing/testing.html (html) > > Nice, I had missed this originally. > >> 3) Translating some old-style test cases to the new TestSuite/TestCase >> structure. > > I think that we should not ship ns-3.6 with both the old and the new > test frameworks. This does not mean that it's a requirement before > merging the new framework but I think that we should focus on cleaning > up this stuff to avoid potential user confusion. i.e., the new code is > duplicating the existing functionality from the Test/TestManager class. > If the new classes are the way forward, we need to kill the old code > and, no, we can't wait because if we wait, no one will ever do it and we > will just accumulate more cruft. Agreed. > >> 6) a mode for verbose tracing and comparison (feature request) >> >>> What about Mathieu's comment recently about having a mode that dumps a >>> lot of trace locally (without downloading saved regression traces) for more >>> extensive regression testing before a checkin? >>> >>> Answer: There aren't any saved regression traces in the sense that we use >>> that term now.... but eventually I >>> would think it would be good to add a flag that is passed down to the test >>> suite via test.py > > If this is not implemented, I would like to see this filed as a bug and > that bug being given a high priority at least for next release. How do you prefer to see this implemented? Note that we lost the ability to call the static EnablePcapAll() function for each device type; now it must be called on a helper object. But, if ascii traces are sufficient, we could have logic that called all those static methods if the flag were passed in. > >> 8) factoring out GSL, or using R-project instead or in addition >> >> > Can we avoid baking in a GSL dependency in case we want to rewrite >> > histogram or chi-squared routines ourselves in the future? >> > >> > Answer: Yes. I don't really relish the idea of writing cumulative >> > distribution functions for various distributions, though. GSL makes >> > statistical tests so much easier to deal with that I think we should >> really >> > begin to use it more. >> > >> > We could try and write a porting layer in between ns-3 and GSL to make it >> > easier to swap in other libraries, but I'm not sure we could get it even >> > close to right unless we knew what those libraries were. > > If this is not implemented, we need to decide if this is a long term > goal, and, if it is, file a bug to keep track of this issue. What would you like to see done here; does the abstraction layer mimic the GSL API? > >> 9) getting lcov reporting to work again; try to make it more explicit to >> developers whether the code coverage is improving or decreasing over time. > > lcov reporting does not work ? Is there a bug report about this ? My mistake, it works fine (just checked). - Tom From tomh at tomh.org Tue Sep 8 22:24:54 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 08 Sep 2009 22:24:54 -0700 Subject: [Ns-developers] ./waf --doxygen-no-build In-Reply-To: <1252435777.2647.4.camel@localhost.localdomain> References: <1252435777.2647.4.camel@localhost.localdomain> Message-ID: <4AA73C26.4080504@tomh.org> Mathieu Lacage wrote: > On Tue, 2009-09-08 at 17:20 +0100, Gustavo Carneiro wrote: >> While documenting the flow monitor code, I have quickly become irritated >> with ./waf --doxygen because it waits for the build to finish before running >> doxygen, which can slow down doxygen when you are only trying to catch >> doxygen errors. So I added ./waf --doxygen-no-build in my tree, which runs >> doxygen before the build is finished. Any objections to adding this to >> ns-3-dev? > > +1 sounds good; thanks also for improving ./waf --check recently. Tom From mathieu.lacage at sophia.inria.fr Tue Sep 8 23:21:02 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 09 Sep 2009 08:21:02 +0200 Subject: [Ns-developers] Testing Framework -- Status and Sneak Peek [long] In-Reply-To: <4AA73BA3.80701@tomh.org> References: <4AA5EE37.1050104@tomh.org> <1252396908.25311.46.camel@diese.inria.fr> <4AA73BA3.80701@tomh.org> Message-ID: <1252477262.8325.16.camel@diese.inria.fr> On Tue, 2009-09-08 at 22:22 -0700, Tom Henderson wrote: > >> 6) a mode for verbose tracing and comparison (feature request) > >> > >>> What about Mathieu's comment recently about having a mode that dumps a > >>> lot of trace locally (without downloading saved regression traces) for more > >>> extensive regression testing before a checkin? > >>> > >>> Answer: There aren't any saved regression traces in the sense that we use > >>> that term now.... but eventually I > >>> would think it would be good to add a flag that is passed down to the test > >>> suite via test.py > > > > If this is not implemented, I would like to see this filed as a bug and > > that bug being given a high priority at least for next release. > > How do you prefer to see this implemented? Note that we lost the > ability to call the static EnablePcapAll() function for each device > type; now it must be called on a helper object. But, if ascii traces > are sufficient, we could have logic that called all those static methods > if the flag were passed in. I have no implementation requirement. The only thing I care about is that we have a way to run all our examples and force enabling of as much tracing as possible in all of them from the command-line and have a way to check that two runs of these traces are identical. Maybe we could add a global HelperEnablePcap GlobalValue in one of the src/helper/.cc files. > >> 8) factoring out GSL, or using R-project instead or in addition > >> > >> > Can we avoid baking in a GSL dependency in case we want to rewrite > >> > histogram or chi-squared routines ourselves in the future? > >> > > >> > Answer: Yes. I don't really relish the idea of writing cumulative > >> > distribution functions for various distributions, though. GSL makes > >> > statistical tests so much easier to deal with that I think we should > >> really > >> > begin to use it more. > >> > > >> > We could try and write a porting layer in between ns-3 and GSL to make it > >> > easier to swap in other libraries, but I'm not sure we could get it even > >> > close to right unless we knew what those libraries were. > > > > If this is not implemented, we need to decide if this is a long term > > goal, and, if it is, file a bug to keep track of this issue. > > What would you like to see done here; does the abstraction layer mimic > the GSL API? I don't know what should be done. From a high-level perspective the question is whether ns-3 should try to avoid a hard gsl dependency or not, and if it is not there, what kind of functionality we can still provide. This, really, is my question: what do people feel should be done about this ? Should we aim hard to build a layer on top of gsl to avoid a hard implementation dependency on it ? Just to be clear, I am not saying we should be doing this _now_ but I would like to clarify what our ultimate goal should be. I really personally don't care much if, when gsl is disabled, parts of the ns-3 models are disabled. So, my request is a request for clarification now as opposed to a request for action now. Mathieu From faker.moatamri at sophia.inria.fr Wed Sep 9 01:59:08 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 09 Sep 2009 10:59:08 +0200 Subject: [Ns-developers] Valgrind fails for optimized static nopython build Message-ID: <4AA76E5C.8040307@sophia.inria.fr> Hi Gustavo, The way to reproduce this under linux is: ./waf configure -d optimized --disable-python --enable-static ./waf ./waf --check --valgrind It will end with target 'ns3module' does not exist This fails on all versions of gcc under linux. Thanks Faker Moatamri From boyko at iitp.ru Wed Sep 9 04:09:33 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Wed, 9 Sep 2009 15:09:33 +0400 Subject: [Ns-developers] AODV model is ready Message-ID: <200909091509.33289.boyko@iitp.ru> Hi! We have finished AODV routing protocol model. This is a brand new implementation, mainly inspired by AODV-UU. The protocol works on top of UDP and is RFC conformable with the following exceptions: - Expanding ring search is not supported, - Local link repair is not implemented. Everybody is welcome to review code at http://codereview.appspot.com/115075/show Repository: https://forge.wenos.ru/hgprojects/ns3aodv/ Example script is examples/aodv. The following files were modified: M src/applications/v4ping/v4ping.cc M src/applications/v4ping/v4ping.h More ping-ish look and feel for ping application. M src/devices/wifi/adhoc-wifi-mac.cc M src/devices/wifi/adhoc-wifi-mac.h TxOk and TxError trace sources to allow layer 2 feedback for layer 3 routing protocols. M src/internet-stack/ipv4-interface.cc M src/internet-stack/ipv4-interface.h Cosmetics: getter and setter for ARP cache. M src/internet-stack/ipv4-l3-protocol.cc Dont set TTL=1 for broadcasts. M src/internet-stack/icmpv4-l4-protocol.cc M src/internet-stack/ipv4-raw-socket-impl.cc M src/internet-stack/tcp-l4-protocol.cc M src/internet-stack/udp-socket-impl.cc Minor fixes -- set protocol field in IP header before route lookup. M src/node/socket.cc Assertions. Any feedback is welcome. Regards, Pavel Boyko, IITP From craigdo at ee.washington.edu Wed Sep 9 11:53:45 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 9 Sep 2009 11:53:45 -0700 Subject: [Ns-developers] Ns-3.6 Release -- The Time to Add Features is Now In-Reply-To: <1252435777.2647.4.camel@localhost.localdomain> References: <1252435777.2647.4.camel@localhost.localdomain> Message-ID: Hi All, Greetings from your friendly neighborhood ns-3.6 release manager. It is time to start putting together a quarterly release of ns-3 already. I have made a release status page on the ns-3 wiki for your enjoyment at http://www.nsnam.org/wiki/index.php/Ns-3.6 As you may know, our release dates are calendar-driven rather than content-driven. This release was originally scheduled for October 7, but that doesn't appear to be possible; so I have pushed the release date back to October 14th and run the important milestones backward in time from that date. The following are the milestones that remain: 6. September 9 -- Late merge period begins (Merge Week Begins); 7. September 16 -- Late merge period ends; 8. September 16 -- Open phase ends; 9. September 16 -- Maintenance phase begins; 10. September 30 -- Maintenance phase ends; 11. September 30 -- Code freeze phase begins; 12. October 1 -- ns-3.6-RC1; 13. October 5 -- ns-3.6-RC2; 14. October 8 -- ns-3.6-RC3; 15. October 12 -- ns-3.6-RC4; 16. October 14 -- ns-3.6 posted; 17. October 14 -- Code freeze phase ends; 18. October 14 -- ns-3.7 Open phase begins. As you can see, we are at the end of the open phase (when new features are added to ns-3) and starting the late merge period today. We encourage people to work to get their code reviewed and pushed into ns-3-dev during the first part of the open phase; but experience tells us that an impending release deadline drives many additions. We are at that deadline. It is now past time to get your features merged into ns-3-dev for inclusion in ns-3.6 if you think they are ready. You have one week to make this happen. On Wednesday, September 16, ns-3-dev will be closed down for new feature additions until after the release is made on Wednesday, October 14. >From what I have uncovered from various list discussions, there are now twelve new-feature candidates that could conceivably go into ns-3.6 (which are also listed on the release wiki page with more details) 1. Flow Monitor 2. MPI-Based Distributed Simulations 3. Nix-Vector Routing 4. Testing and Validation Framework 5. WiMAX Models 6. Multi-Channels in YANS Wifi Phy 7. 802.11 10 MHz Channel 8. 802.11s Mesh Model 9. NetAnim Animator Support 10. Underwater Acoustic Network Device and Channel 11. Patch to Pause and Resume an Interface 12. PacketBB (RFC 5444) According to the book of instructions of ns-3, if you want to get your addition merged into the release you will be expected to provide the following: - A mercurial patch, bundle or repo against the current version of ns-3-dev that contains your proposed feature addition. You need to make sure that I can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests successfully on all of our target machines; - A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this will be used to generate release notes and will be provided to maintainers if a code review is indicated -- updated release notes in the patch would be great); - Some kind of unit or regression test that I can use to determine if your feature is actually working at each stage of the integration. Once I have all of this information, I will ping the reviewer(s) for a final approval and push your feature(s) to the mainline code. If I run into problems merging your code, I will most likely just set your package aside so please make sure it all works -- we don't have time for debugging problems at this stage! Just merging, building and running all of the tests is going to take me at least several hours per feature, though. With twelve feature additions possible over the next week, this translates to over two major merges per business day, which, well, just isn't going to happen. We are obviously going to have to sort and prioritize the work. I will work with some of the project leaders to figure this out when the time comes. The first criterion I am going to use in prioritizing work is FIFO. Whoever gets me their fully reviewed and tested patch first, goes into ns-3.6 first. This is a big hint to get your package together and tidied up and send it to me as soon as possible. If you feel you are blocked by something that should be resolvable quickly, let me know. You don't have much time left. If you don't have a reviewed patch that can be made ready to go virtually immediately, I don't think your chances are good for getting into ns-3.6 -- maybe you should consider trying for merge in the open phase of ns-3.7 that starts on October 14th. You can *try* to sneak in at the deadline, but there are no guarantees. We are getting down to the wire, so if you want to get into ns-3.6, you should email me (preferably copying the list) now with status and pointers to your bits. I will begin pushing features as soon as I have them in my queue with final approval. It is really up to you to make your feature additions happen. We don't have much time left. Regards, -- Craig From craigdo at ee.washington.edu Wed Sep 9 15:26:39 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 9 Sep 2009 15:26:39 -0700 Subject: [Ns-developers] WiMAX review request In-Reply-To: <4AA64AE3.4020809@sophia.inria.fr> References: <4AA64AE3.4020809@sophia.inria.fr> Message-ID: > Hi all, > I would like to ask you kindly to review the WiMAX module code. Wow. Lots of code. Didn't make it through everything. I know this is coming late, but I have comments. 1. It's just a nit, but there is a tendency in wimax.h to use acronyms before definition. In many cases you find things like "MAC Common Part Sublayer (CPS)" which is perfect, but many other acronyms are used well before you find the definition and they are never explicitly tied together. Overall this is a quite nice file, though. 2. In wimax.h, "The process to determine if a block is received correctly has x steps" should be fixed. 3. In wimax,h, "From a pre-generated trace files determine the bloc error rate for the calculated SNR". I don't anyone will understand what this means at all unless they've read the code. Need to explain this further since this is the first thing a user will read about the model. 4. The following seems wrong: "2 regression tests based on example scenarios have been developed. To execute these tests we should compile the module with "WIMAX_TEST" flag: CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf" Regression tests are run on examples which are compiled with and link to standard ns-3 libraries; and use trace files to determine PASS or FAIL status. You can't have a regression test that depends on a separately compiled model and which generates no data. This may be something you can use to test WiMAX, but it isn't an ns-3 regression test runnable in the nightly build and test cycle like every other regression test. Regression tests typically don't print output. Some of the examples do. It sounds like this should be integrated into the new test framework before release. Luckily this is easy to do and I can help. 5. examples/wimax-ipv4.cc: Why does this invent a new argument parsing mechanism? This makes it different from all other examples in program structure and usage. 6. examples/wimax-ipv4.cc: I think you should make it more clear what topology you are creating, what the example is supposed to do and provide comments in the code. wimax.ClassifierConfig (ss[i + (nbSS / 2)], ss[i], bs[0], Sinterfaces.GetAddress (i + (nbSS / 2)), SSinterfaces.GetAddress (i), 0, 100 + (i * 10), 17, 100); Is not terribly helpful in terms of understanding what the example is doing. 7. examples/wimax-multicast.cc: This shouldn't have: NS_LOG_COMPONENT_DEFINE ("MySimpleWimaxSimulation"); 8. examples/wimax-multicast.cc: See (6). 9. examples/wimax-simple.cc: See (6). 10. examples/wimax.cc: See (6) and (7), 11. The examples all seem to have different argument parsing routines with different argument styles (i.e., -c vs. --Help). 12. trace-based-streamer.cc: You push characteristics of the trace to five separate vectors. I would've expected to see these things combined into an object and pushed into one vector. Something like, typedef struct { Time tSend; uint32_t size; uint32_t frameIndex; char[n] frameType; } TraceEntry; TraceEntry entry; entry.tSend = ... m_entries.push_back (entry); 13. trace-based-streamer.cc: You load the trace when the application is starting. This is okay unless you are running in real time. IN this case it would be better to load the trace before the time-critical things start happening in the simulation -- i.e., at configuration time. 14. trace-based-streamer.cc: In TraceBasedStreamer::Send (void) I find lots of malloc() but no corresponding free(). Has this been run through valgrind? 15. trace-based-streamer.cc: The strcpy in TraceBasedStreamer::TraceBasedStreamer() is redundant memset (m_traceFile, 0, 1024); strcpy (m_traceFile, ""); 16. trace-based-streamer.h: Doxygen is \ingroup udpecho with \brief A Udp Echo Client. 17. trace-based-streamer.h: No Doxygen for methods of TraceBasedStreamer 18. src/applications/udp-client-server: I don't understand what this is all about. Why is this different than a udp-echo application? What does udp-client-server mean? The Doxygen calls it a Udp Echo client and server. Why not use or extend existing Udp Echo? Did you duplicate an application to add a sequence number? 19. src/applications/udp-client-server: This all needs Doxygen. 20. What is this? diff -r 7dd4ad5ac045 src/devices/wimax/.directory --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/devices/wimax/.directory Thu Sep 03 15:07:19 2009 +0200 @@ -0,0 +1,3 @@ +[Dolphin] +Timestamp=2009,8,27,9,21,49 +ViewMode=1 21. src/devices/wimax/README: Doesn't this just duplicate wimax.h? Why have two places with the same information in it? One will get stale. 22. bs-link-manager.cc: Do you really want to LogComponentEnable ("BSLinkManager", LOG_LEVEL_INFO) in BSLinkManager::BSLinkManager()? 23. bs-link-manager.cc: In BSLinkManager::CalculateRangingOppsToAllocate (void) //randomly selecting TOs up to 10, shall actually be decided by scheduler return rand () % 8 + 2; Is this really what you want? Should probably say randomly select TO from 2 to 10, then. Hard coded numbers could be changed to const uint8_t for clarity. 24. in BSLinkManager::PerformRanging(): If it was worthwhile putting in debug printfs, it would probably good to use NS_LOG. #ifdef JDEBUG1 std::cout << std::endl << "RNG-REQ"; rngreq.Print (std::cout); std::cout << std::endl; #endif 25. In BSLinkManager::PerformInitialRanging() I see SSRecord *ssRecord = new SSRecord (); bool isOldSS = m_bs->GetSSManager ()->IsInRecord (rngreq->GetMacAddress ()); if (isOldSS) { ssRecord = m_bs->GetSSManager ()->GetSSRecord (rngreq->GetMacAddress ()); //if this fails it would mean the RNG-RSP with success status was not received by the SS } New SSRecord is overwritten with no delete? Has this been run through valgrind? In fact, I don't see a delete anywhere. If there is supposed to be responsibility for the object passed somewhere else, this kind of thing should be explicitly stated. 26. In bs-link-manager.cc, this kind of stuff shouldn't be in released code ... void BSLinkManager::DeallocateCids (Ptr cid) { //if necessary, delete entire connections or simply set CIDs to 0 } uint64_t BSLinkManager::SelectDlChannel (void) { //temporarily set to 1 for quick scanning return m_bs->GetChannel (1); } bool BSLinkManager::ChangeDlChannel (void) { //code to decide if SS shall move to a new channel/frequency goes here return false; //temp } uint32_t BSLinkManager::GetNewDlChannel (void) { //code to determine suggested new frequency goes here return 100; //temp } 27. bs-link-manager.h: Needs Doxygen. 28. bs-scheduler-rtps.cc: a newed list goes in m_downlinkBursts during construction BSSchedulerRtps::BSSchedulerRtps (Ptr bs) : m_downlinkBursts ( new std::list > > ()) { SetBs (bs); } m_downlinkBursts is just deleted on destruction BSSchedulerRtps::~BSSchedulerRtps (void) { SetBs (0); delete m_downlinkBursts; m_downlinkBursts = 0; } but other things are newed up and put in void BSSchedulerRtps::AddDownlinkBurst (Ptr connection, uint8_t diuc, WimaxPhy::ModulationType modulationType, Ptr burst) { OfdmDlMapIe *dlMapIe = new OfdmDlMapIe (); [ ... ] m_downlinkBursts->push_back (std::make_pair (dlMapIe, burst)); } Has this been run through valgrind? If this is handled somewhere else, the responsibility for allocating and freeing objects should be written down explicitly. 29. in BSSchedulerRtps::Schedule (void) there is ifdef JDEBUG2. See (24). 30. In BSSchedulerRtps::CreateUgsBurst, I see NS_ASSERT (burst->GetSize ()); I really like to see messages associated with asserts (NS_ASSERT_MSG) 31. in BSSchedulerRtps::BSSchedulerRTPSConnection() there are several of std::cout << "\tDL Scheduler for rtPS flows \n" << "\t\tavailableSymbols = " << availableSymbols << std::endl; You shouldn't just write things to stdout. This should be NS_LOG something. 32. bs-scheduler-rtps.h: Needs more Doxygen. 33. bs-scheduler-simple.cc: Similar memory management questions as (28). 34. bs-scheduler-simple.cc: JDEBUGs sould be NS_LOGs 35. bs-scheduler-simple.h needs Doxygen. 36. bs-scheduler.h needs Doxygen. 37. burst-profile-manager.h /*Note: This class shall actually be a baseclass subclassed by the BS and SS since the two will have different functionaities*/ A confusing statement. 38. burst-profile-manager.h needs Doxygen 39. connection-identifier-factory.cc: Lots of hardcoded hex numbers. 40. connection-identifier-factory.h needs Doxygen 41. connection-manager.cc ConnectionManager::ConnectionManager (void) : m_cidFactory (0), m_connectionSetupList (new std::list >, std::pair > > >), m_connectionSetupList2 (new std::list< std::pair > >) { } Two new operations ConnectionManager::~ConnectionManager (void) { delete m_connectionSetupList; m_connectionSetupList = 0; } But only one delete. Has this been run through valgrind? My eyes are starting to cross and patterns are developing so I'll just finsh here. I am concerned about the understandability of examples and the different argument parsing. I don't like the scattered writes to standard out very much. I am concerned about Doxygen completeness, the lack of standard tests and I am very concerned about memory management. I'd like to see valgrind-clean runs before trying to merge any of this ... Regards, -- Craig > -----Original Message----- > From: ns-developers-bounces at ISI.EDU > [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of Faker Moatamri > Sent: Tuesday, September 08, 2009 5:16 AM > To: ns-3-reviews at googlegroups.com; ns-developers at ISI.EDU > Subject: [Ns-developers] WiMAX review request > > Hi all, > I would like to ask you kindly to review the WiMAX module code. The > WiMAX module implements the 802.16 specification. > Here is the list of new/changed files: > > New files: > Added a new directories: > src/devices/wimax > src/applications/trace-based-streamer > src/applications/udp-client-server > Added new files: > examples/wimax.cc > examples/wimax-ipv4.cc > examples/wimax-mulicast.cc > examples/wimax-simple.cc > src/helper/trace-based-streamer-helper.cc/h > src/helper/udp-helper.cc/h > src/helper/wimax-helper.cc/h > Changed: > src/common/pcap-writer.cc/h > src/core/config.h > > Documentation: > It can be found in src/devices/wimax/README, there is also > the attached > wimax.h file which will be finalized and added to the tree > once finished. > > Compiling and building: > Requirments: This module requires the presence of the *IT++ > library*, under linux you can install it simply using yum/apt-get > depending on your distribution. Without this library, the wimax code > will be ignored and it will not be compiled. We plan to remove this > dependency on IT++ for next release. > Getting the code: > - You can download the code from > http://code.nsnam.org/iamine/ns-3-wimax-release/ , it is > merged with the > revision 4750 of ns-3-dev > - You can use the attached patch and apply it on > revision 4750 > of ns-3-dev > Compile and build: > - You use the usual ./waf configure, you should have WiMAX > module : Enabled to be sure that wimax will be compiled and built > - ./waf to compile and build > Testing: > WiMAX module testing is based on 2 example scenarios that are > used for > regression testing. > To enable the testing you compile with WIMAX_TEST flag: > CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf > > You run the tests simply by running the examples: > wimax-ipv4 > wimax-multicast > You can also specify the scheduling type using -s option: [-s > scheduling_type] > The scheduling type can be: > - 0 for SCHED_TYPE_SIMPLE (default) > - 1 for SCHED_TYPE_MBQOS > - 2 for SCHED_TYPE_RTPS > > You should get ok as output of the tests. > > Reviewing the code: > The code has been uploaded to the Rietveld reviewing tool: > http://codereview.appspot.com/115051 > You can review and put comments on the code. > Thank you very much > Faker Moatamri > > > From tomh at tomh.org Wed Sep 9 23:23:24 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 09 Sep 2009 23:23:24 -0700 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <200907051312.34742.boyko@iitp.ru> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu> <1246728906.2514.1.camel@localhost.localdomain> <200907051312.34742.boyko@iitp.ru> Message-ID: <4AA89B5C.5020206@tomh.org> Pavel Boyko wrote: > Hi, > > I'm happy to announce that 802.11s mesh stack model is stable enough to be > merged into the mainline. I have created one bug and three code review issues > for that. They are (in order to be reviewed/resolved): > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=623 -- trivial but really wanted > patch. > > http://codereview.appspot.com/91057/show -- multichannel support in yans wifi > channel and PHY. Basically each yans PHY has channel id and yans channel > delivers packets only between PHY with the same channel ids. Channel center > frequency is calculated from channel id in the standard specific way. > There is a configurable channel switch delay. There is no inter channel > interference for now, but it can be easily added. For now only mesh interface > MAC is aware of multichannel PHY. > > http://codereview.appspot.com/88093/show -- a bundle of small and harmless > changes in the wifi module needed to support 802.11s. > > http://codereview.appspot.com/88094/show -- the 802.11s model itself. This > review issue succeed to Faker's review (issue 63188). Most of his comments are > accepted. > > Everybody is welcome to participate in the review. One can find mesh stack > arch. description here -- http://www.nsnam.org/wiki/index.php/Mesh and > original repository here -- https://forge.wenos.ru/hgprojects/ns3dev Pavel and all, I reviewed this again tonight since it is close to merging. I reviewed mainly for documentation/examples/logging/test purposes tonight; not so much for coding style or code logic itself. Main comments/questions: 1) Attributes and trace system: There are very few trace sources (I found two), and lots of parameters that exist outside of the attribute system and require setters/getters (e.g. MeshWifiInterfaceMac class, PeerLink class). 2) Did you look at the existing statistics framework before implementing MeshPointDevice::Report()? I'm curious whether you elected to do this despite the stats framework or because you didn't know about it (contrib/stats). It seems like you want to be able to query at the end of the simulation for various counters. 3) Nice to see six new unit tests 4) Doxygen seems incomplete. Also, I don't believe that these types of single line Doxygen comments are valid: /// Access current routing protocol Ptr GetRoutingProtocol () const; the /// doxygen comment needs to be two lines at least (see: http://www.stack.nl/~dimitri/doxygen/docblocks.html), and furthermore there is mixing of styles (/** and ///) in the same file (please try to use one) 5) examples/mesh.cc seems to be trying to be both a test program and an example program. I would recommend that the existing one be an example. The example program should have a block of comments about what the program is intended to demonstrate. I would also recommend a block of comments in the body of MeshTest::CreateNodes() that goes into more detail about the mesh configuration. Separately, we probably need a test/regression program or two. 6) NS_LOG calls seem incomplete or inconsistent. In general, in src/devices/mesh, mostly there are NS_LOG_FUNCTION calls for only mesh-wifi-interface-mac.cc and mesh-point-device.cc, but not much at DEBUG, LOGIC, WARN level. In contrast, there are very few NS_LOG_FUNCTION calls in the dot11s or flame subdirectories. Logging tends to be very useful for routing protocols. A couple of nits: ----- - could mesh-helper.h, mesh-stack-installer.h, and flame-installer.h all just be combined into one helper? - in examples/mesh.cc, it is a bit confusing to see the reuse of the local variable named "m_stack" - MeshArchitecture could refer to your actual L2 protocols instead of Foo and Bar That's all I have for today; in summary, this looks close but a final push for attribute cleanup, documentation, logging seems warranted. Tom From boyko at iitp.ru Thu Sep 10 00:39:38 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 10 Sep 2009 11:39:38 +0400 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <4AA89B5C.5020206@tomh.org> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu> <200907051312.34742.boyko@iitp.ru> <4AA89B5C.5020206@tomh.org> Message-ID: <200909101139.38682.boyko@iitp.ru> Hello, Tom, Thank you for quick response! > Main comments/questions: > 1) Attributes and trace system: There are very few trace sources (I > found two), and lots of parameters that exist outside of the attribute > system and require setters/getters (e.g. MeshWifiInterfaceMac class, > PeerLink class). Do you really want to attach attribute to every setter? Now we use attributes only for externally user-configurable parameters (and we have 37 such attributes in mesh subsystem + all inherited ones). All the other getters and setters are _just_ getters and setters, used in the mesh stack implementation. > > 2) Did you look at the existing statistics framework before implementing > MeshPointDevice::Report()? I'm curious whether you elected to do this > despite the stats framework or because you didn't know about it > (contrib/stats). It seems like you want to be able to query at the end > of the simulation for various counters. We report not only counters, but also routing tables, open links, known network topologies, etc. This is very flexible, comparing to stats-based approach. Users, interested in mesh internals research can find this reports useful and easily extend them, the others can just ignore that functionality. > 4) Doxygen seems incomplete. Well, frankly speaking we are proud of our doxygen documentation, almost every class and method and member of every class is documented and classes are structured into several doxygen modules. This hardly can be said about the rest of ns-3. Please point me undocumented classes/methods and we will fix that. > Also, I don't believe that these types of > single line Doxygen comments are valid: > > /// Access current routing protocol > Ptr GetRoutingProtocol () const; > > the /// doxygen comment needs to be two lines at least (see: > http://www.stack.nl/~dimitri/doxygen/docblocks.html), C++ style one-liner means brief comment in doxygen, grep your own reference above for "A third option is to use a special C++ style comment which does not span more than one line". So /// blah-blah-blah means exactly the same as /** * \brief blah-blah-blah */ Single line form is especially useful when you really document _every_ member, if later notation is used the half of lines in your header will be stars and slashes. > and furthermore > there is mixing of styles (/** and ///) in the same file (please try to > use one) One line comments are //, multiple line ones are /**/. What's wrong? > 5) examples/mesh.cc seems to be trying to be both a test program and an > example program. I would recommend that the existing one be an example. This can be said about almost all programs in examples/. > The example program should have a block of comments about what the > program is intended to demonstrate. I would also recommend a block of > comments in the body of MeshTest::CreateNodes() that goes into more > detail about the mesh configuration. Agree, will do this asap. > Separately, we probably need a test/regression program or two. Agree, but let us do this after test system rework will be completed. Ok? > > 6) NS_LOG calls seem incomplete or inconsistent. In general, in > src/devices/mesh, mostly there are NS_LOG_FUNCTION calls for only > mesh-wifi-interface-mac.cc and mesh-point-device.cc, but not much at > DEBUG, LOGIC, WARN level. In contrast, there are very few > NS_LOG_FUNCTION calls in the dot11s or flame subdirectories. Logging > tends to be very useful for routing protocols. We extensively use logging for debug (as well as packet traces, debugger and so on), but we do not obey any kind of logging policy. If you find this important -- please update coding style manual. For now I propose do not blindly instrument mesh code with logging. > A couple of nits: > ----- > - could mesh-helper.h, mesh-stack-installer.h, and flame-installer.h all > just be combined into one helper? Will consider this, > - in examples/mesh.cc, it is a bit confusing to see the reuse of the > local variable named "m_stack" Good point, this is a by-product of blind code style fixes (replace everything -> m_everything). Will fix asap. > - MeshArchitecture could refer to your actual L2 protocols instead of > Foo and Bar No, I find this important that mesh architecture is independent of actual protocols and stacks of them. > That's all I have for today; in summary, this looks close but a final > push for attribute cleanup, documentation, logging seems warranted. Good. We will update codereview patchset asap. Thank you. Pavel From boyko at iitp.ru Thu Sep 10 00:52:55 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 10 Sep 2009 11:52:55 +0400 Subject: [Ns-developers] Ns-3.6 Release -- The Time to Add Features is Now In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> Message-ID: <200909101152.55416.boyko@iitp.ru> On Wednesday 09 September 2009 10:53:45 pm craigdo at ee.washington.edu wrote: > From what I have uncovered from various list discussions, there are now > twelve new-feature candidates that could conceivably go into ns-3.6 (which > 7. 802.11 10 MHz Channel This is already merged (together with 5MHz channel). M.b. Ramon should just update release notes? Pavel From tomh at tomh.org Thu Sep 10 07:55:49 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 10 Sep 2009 07:55:49 -0700 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <200909101139.38682.boyko@iitp.ru> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu> <200907051312.34742.boyko@iitp.ru> <4AA89B5C.5020206@tomh.org> <200909101139.38682.boyko@iitp.ru> Message-ID: <4AA91375.2010306@tomh.org> Pavel Boyko wrote: > Hello, Tom, > > > Thank you for quick response! > > > > Main comments/questions: > > 1) Attributes and trace system: There are very few trace sources (I > > found two), and lots of parameters that exist outside of the attribute > > system and require setters/getters (e.g. MeshWifiInterfaceMac class, > > PeerLink class). > > > Do you really want to attach attribute to every setter? Now we use > attributes only for externally user-configurable parameters (and we have > 37 such attributes in mesh subsystem + all inherited ones). All the > other getters and setters are _just_ getters and setters, used in the > mesh stack implementation. OK, I trust that you've identified the attributes that you think should be exposed. I just grepped for setters and they do not seem to be related to attributes. Trace sources can be added as needed. > > > > > > 2) Did you look at the existing statistics framework before implementing > > MeshPointDevice::Report()? I'm curious whether you elected to do this > > despite the stats framework or because you didn't know about it > > (contrib/stats). It seems like you want to be able to query at the end > > of the simulation for various counters. > > > We report not only counters, but also routing tables, open links, known > network topologies, etc. This is very flexible, comparing to stats-based > approach. Users, interested in mesh internals research can find this > reports useful and easily extend them, the others can just ignore that > functionality. The reason that I ask is that we have a proposed statistics framework (in src/contrib) that very few people (AFAICS) are using, and it seems like you implemented your own, which suggests to me that either you didn't like the existing one enough or weren't aware of it. The problem of getting counters at the end of a simulation run, and doing more sophisticated things with these counters like simulation run-length control, is a general one, and we do have initial facilities for this type of reporting (traced variables, stats data collectors), so when I see someone work outside this framework, it makes me wonder whether the provided ones are known or adequate. > > > > 4) Doxygen seems incomplete. > > > Well, frankly speaking we are proud of our doxygen documentation, almost > every class and method and member of every class is documented and > classes are structured into several doxygen modules. This hardly can be > said about the rest of ns-3. Please point me undocumented > classes/methods and we will fix that. I did not mean to disparage your effort here; there is quite a lot of doxygen and I see that you made use of grouping which AFAIK is not done yet in the existing ns-3 tree. Within the groups, the methods are ususally not further documented but I think that these uncommented methods probably are trivial enough that the signal to noise ratio of doxygen is low. Likewise, if you find undoxygenated ns-3 public headers, please file a bug or patch. We know (and there is a bug about) the lack of doxygen in src/helper, but in general, we are trying to keep this complete, and I think there is fairly good coverage for the most part. > > > > Also, I don't believe that these types of > > single line Doxygen comments are valid: > > > > /// Access current routing protocol > > Ptr GetRoutingProtocol () const; > > > > the /// doxygen comment needs to be two lines at least (see: > > http://www.stack.nl/~dimitri/doxygen/docblocks.html), > > > C++ style one-liner means brief comment in doxygen, grep your own > reference above for "A third option is to use a special C++ style > comment which does not span more than one line". So > > > /// blah-blah-blah > > > means exactly the same as > > > /** > * \brief blah-blah-blah > */ > > Single line form is especially useful when you really document _every_ > member, if later notation is used the half of lines in your header will > be stars and slashes. > > > > and furthermore > > there is mixing of styles (/** and ///) in the same file (please try to > > use one) > > > One line comments are //, multiple line ones are /**/. What's wrong? OK, all of these are related to my unfamiliarity with /// markup, which I don't believe anyone has used. What tends to be lost with this style is documentation of function parameters. That being said, I think you pointed out that more verbose notation that we typically use tends to make the headers less readable since they are not as compact. So, I'm not going to quibble about your choice here; thanks for pointing it out. > > > 5) examples/mesh.cc seems to be trying to be both a test program and an > > example program. I would recommend that the existing one be an example. > > > This can be said about almost all programs in examples/. > > > > The example program should have a block of comments about what the > > program is intended to demonstrate. I would also recommend a block of > > comments in the body of MeshTest::CreateNodes() that goes into more > > detail about the mesh configuration. > > > Agree, will do this asap. > > > > Separately, we probably need a test/regression program or two. > > > Agree, but let us do this after test system rework will be completed. Ok? Yes. > > > > > > 6) NS_LOG calls seem incomplete or inconsistent. In general, in > > src/devices/mesh, mostly there are NS_LOG_FUNCTION calls for only > > mesh-wifi-interface-mac.cc and mesh-point-device.cc, but not much at > > DEBUG, LOGIC, WARN level. In contrast, there are very few > > NS_LOG_FUNCTION calls in the dot11s or flame subdirectories. Logging > > tends to be very useful for routing protocols. > > > We extensively use logging for debug (as well as packet traces, debugger > and so on), but we do not obey any kind of logging policy. If you find > this important -- please update coding style manual. For now I propose > do not blindly instrument mesh code with logging. There is no strict requirement for logging statements, and I don't think we want to impose one, but in general, I think it is helpful to instrument the main control flow with LOG_FUNCTION calls, so people can trace the packet through the system. My main comment was that it seemed (from scanning the code) that there wasn't any consistency to what you were trying to do with logging. Three files were heavily logged with NS_LOG_FUNCTION and the rest did not have any instances of NS_LOG_FUNCTION. If you feel that you have an adequate and consistent logging approach (because those three are the only ones that warrant such type of function logging), I can let this comment go. In summary, thanks for your quick response, and I think we should try to merge this for ns-3.6. Tom From craigdo at ee.washington.edu Thu Sep 10 13:03:33 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 10 Sep 2009 13:03:33 -0700 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <4AA91375.2010306@tomh.org> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu><200907051312.34742.boyko@iitp.ru> <4AA89B5C.5020206@tomh.org><200909101139.38682.boyko@iitp.ru> <4AA91375.2010306@tomh.org> Message-ID: <4E32E6229DF945DB9B1C28F76A56DAF3@CRAIGVAIO> > > One line comments are //, multiple line ones are /**/. What's wrong? Nothing is technically wrong with this. Nothing is technically wrong with mixing indentation, or using half gnu formatting and half whitesmiths. Nothing is wrong with a file that has half of its comments using /* */ and half with // only. It all compiles just fine. It's about coding standards, of course. Nobody likes them very much, and lots of people argue about them. You are probably already very tired of ns-3 coding standards. I've been tired of coding standards for the last thirty years; but I live with them for the same reasons I live with dental work. This is a boundary case which probably isn't documented anywhere; but we decided a while back that when we added to a file, we would align with the existing style. I was going to mention this in my review of the code. > That being said, I think you pointed out that more verbose > notation that > we typically use tends to make the headers less readable > since they are > not as compact. As is typical for style debates, I think the dense style actually tends to make the code *less* readable. Of course, others will disagree in other ways. We are never *all* going to agree that some particular combination of styles is the best way, so we all have got to live with things we think are sub-optimal. Because we value Doxygen content over Doxygen formatting we tend to try and be accommodating Doxygen-style-wise. The one thing we do ask is to leave files stylistically consistent. If a file is all /// then we leave it that way when we add something. If a file is /*** */ we leave it. If a file uses \brief we don't add new Doxygen with @brief. Etc, etc. We like consistency. Anyway, I don't think anyone is going to hold up your submission because you used ///, but don't be surprised if someone changes it during one of our periodic Doxygenation sweeps through the system; and don't be surprised if other reviewers notice it since it is inconsistent with respect to the rest of the system. So, for future reference, we would like existing styles of code and documentation to be respected when additions are made. However, if we are going to spend time mentioning it and writing words about it, something to this effect should be put in the coding standard document. -- Craig From craigdo at ee.washington.edu Thu Sep 10 13:09:17 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 10 Sep 2009 13:09:17 -0700 Subject: [Ns-developers] Ns-3.6 Release -- The Time to Add Features isNow In-Reply-To: <200909101152.55416.boyko@iitp.ru> References: <1252435777.2647.4.camel@localhost.localdomain> <200909101152.55416.boyko@iitp.ru> Message-ID: <501900381DE44F3BAEACEBB4EA40C7F0@CRAIGVAIO> > > From what I have uncovered from various list discussions, > there are now > > twelve new-feature candidates that could conceivably go > into ns-3.6 (which > > > 7. 802.11 10 MHz Channel > > This is already merged (together with 5MHz channel). M.b. > Ramon should just > update release notes? CHANGES.html and RELEASE_NOTES should reflect these additions. -- Craig From boyko at iitp.ru Fri Sep 11 06:50:51 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Fri, 11 Sep 2009 17:50:51 +0400 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <4E32E6229DF945DB9B1C28F76A56DAF3@CRAIGVAIO> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu> <4AA91375.2010306@tomh.org> <4E32E6229DF945DB9B1C28F76A56DAF3@CRAIGVAIO> Message-ID: <200909111750.52033.boyko@iitp.ru> Hi Craig, On Friday 11 September 2009 12:03:33 am craigdo at ee.washington.edu wrote: > Anyway, I don't think anyone is going to hold up your submission because So, I didn't catch your final resolution -- do you support merge into the mainline now? If so, do you need a patch or you can pull from our repository? Pavel From mk.banchi at gmail.com Fri Sep 11 06:43:53 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 11 Sep 2009 15:43:53 +0200 Subject: [Ns-developers] Patch for bug #602 Message-ID: <3C36687C-6EBE-4494-84C3-8BD32319EC18@gmail.com> I have created a patch for bug 602. It's available on bugzilla. A feedback would be great. Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090911/46122827/smime.bin From tom5760 at gmail.com Fri Sep 11 09:29:55 2009 From: tom5760 at gmail.com (Tom Wambold) Date: Fri, 11 Sep 2009 12:29:55 -0400 Subject: [Ns-developers] Ns-3.6 Release -- The Time to Add Features is Now In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> Message-ID: On Wed, Sep 9, 2009 at 2:53 PM, wrote: > >From what I have uncovered from various list discussions, there are now > twelve new-feature candidates that could conceivably go into ns-3.6 (which > are also listed on the release wiki page with more details) > > [...] > ?12. PacketBB (RFC 5444) Craig: I believe that my PacketBB code is ready for merging. I have made the changes others have suggested such as removing the separate namespace, and filling out doxygen comments. > According to the book of instructions of ns-3, if you want to get your > addition merged into the release you will be expected to provide the > following: > > - A mercurial patch, bundle or repo against the current version of ns-3-dev You can find my repo at [1]. The only changes are the new files: * src/node/packetbb.{cc,h} * src/node/test-packetbb.cc > - A summary of the additions you are proposing I suppose a pretty simple summary could be: * Adds library for constructing/reading PacketBB (RFC 5444) packet formats. > - Some kind of unit or regression test that I can use to determine if your > feature is actually working at each stage of the integration. There is a fairly extensive test program in the repository at [1] under src/node/test-packetbb.cc. I plan to port this to the new testing framework once it gets merged. Please let me know if you need anything else, or if anyone find any issues with the code. Thanks! -Tom Wambold From egemen.cetinkaya at gmail.com Thu Sep 10 18:39:42 2009 From: egemen.cetinkaya at gmail.com (Egemen Cetinkaya) Date: Thu, 10 Sep 2009 20:39:42 -0500 Subject: [Ns-developers] Development of new routing protocol Message-ID: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> Hi, We are wondering if anyone is developing AODV, DSR, DSDV for ns-3? I saw couple of threads once I Googled AODV and ns-3, but wanted to make sure that if we are intending to develop new protocol, we are not going to duplicate the efforts. Also if AODV is in the pipe, what's the next routing protocol that user's would like to see most? Thanks, Egemen Cetinkaya From ian.thomson at gmail.com Fri Sep 11 10:32:26 2009 From: ian.thomson at gmail.com (Ian Thomson) Date: Fri, 11 Sep 2009 18:32:26 +0100 Subject: [Ns-developers] Development of new routing protocol In-Reply-To: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> References: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> Message-ID: <20a651590909111032o3739aed8j807a4a640a471377@mail.gmail.com> Hello I believe Pavel Boyko has finished work on AODV. I am intending on implementing DSR for ns-3, but i have not yet submitted a proposal. Regards Ian Thomson On Fri, Sep 11, 2009 at 2:39 AM, Egemen Cetinkaya wrote: > Hi, > > We are wondering if anyone is developing AODV, DSR, DSDV for ns-3? > > I saw couple of threads once I Googled AODV and ns-3, but wanted to make > sure that if we are intending to develop new protocol, we are not going to > duplicate the efforts. > > Also if AODV is in the pipe, what's the next routing protocol that user's > would like to see most? > > Thanks, > > Egemen Cetinkaya > From craigdo at ee.washington.edu Fri Sep 11 12:34:47 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 11 Sep 2009 12:34:47 -0700 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <200909111750.52033.boyko@iitp.ru> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu><4AA91375.2010306@tomh.org><4E32E6229DF945DB9B1C28F76A56DAF3@CRAIGVAIO> <200909111750.52033.boyko@iitp.ru> Message-ID: <064F5E83FA324A2290E565F7C58006F4@CRAIGVAIO> > So, I didn't catch your final resolution -- do you support > merge into the > mainline now? If so, do you need a patch or you can pull from > our repository? Hi Pavel, Overall I think this is very nice and you seem to have gone above and beyond the strict call of duty on this one. Good job. I think you are almost ready to go. Like almost all models in ns-3, there are holes in the Doxygen. However, this is better than most so I won't complain. I have a few nits (see below), but I won't hold you up on any of them at this late date. Feel free to make changes if you want :-) What I need now is (roughly from the ns-3.6 page): - A mercurial patch, bundle or repo against the current version of ns-3-dev that contains your proposed feature addition. You need to make sure that I can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests successfully on all of our target machines; - A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this is used to geminate release notes and changes -- if you could update RELEASE_NOTES and CHANGES.html that would be perfect); - Some kind of unit or regression test that I can use to determine if your feature is actually working. We need to deal with a system test for this code. It'll be hard for you to write a system test since the testing framework isn't pushed yet, though :-). In the patch, you provide an examples/mesh.cc but that seems to just print results. This should be converted to the test framework as a system test before release. I'm happy to merge your code and then file a P1 bug on this. I will convert your unit tests to the new test framework so you don't have to worry about that. So, I really just need a final repository to pull from. Have you run this on all of our supported machines? Have you compiled the Doxygen and looked at the output? If so, just point me to your final code and you will go into the merge queue at position three. I expect you will find your code integrated when you come to work Monday morning. Regards, -- Craig Nits: 1. You probably saw my comments regarding the /// Doxygen style additions in a follow-up to Tom's review. 2. In examples/wscript: Should there be a dependency on 'mesh'? obj = bld.create_ns3_program('mesh', ['core', 'simulator', 'mobility', 'wifi']) obj.source = 'mesh.cc' 3. In src/devices/mesh/dot11s/hwmp-protocol.cc: Coding standard: should_send s/b shouldSend, packet_copy s/b packetCopy, etc. 4. I prefer NS_ASSERT_MSG to NS_ASSERT to give users context if the code dies. 5. src/devices/mesh/dot11s/ie-dot11s-beacon-timing.h: Coding standard: last_beacon, beacon_interval 6. src/devices/mesh/dot11s/ie-dot11s-perr.cc: Sie of Mac48Address (not German? :-) 7. src/devices/mesh/dot11s/ie-dot11s-perr.cc: Inconsistent placement of & in const IePerr & a vs. std::ostream &os. 8. src/devices/mesh/dot11s/ie-dot11s-prep.cc: Coding standard: dest_seq_number, dest_address, etc. 9. src/devices/mesh/dot11s/ie-dot11s-preq.cc: Various numeric constants could be named for clarity. From craigdo at ee.washington.edu Fri Sep 11 12:56:08 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 11 Sep 2009 12:56:08 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> Message-ID: <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> Hi All, We have three features queued up for addition into ns-3.6 at this time. These features will be serialized and merged into ns-3-dev over the next couple of days. 1. Testing and Validation Framework 2. PacketBB (RFC 5444) 3. 802.11s Mesh Model I will start the process on these features this afternoon; and if all goes well these should all be part of the new and improved ns-3-dev by Monday. If everyone could take a look as these features appear and exercise them as much as possible I would be grateful beyond words. You may even win the weekly ns-3.6 release door prize if you find problems. Some say that receiving this award was the high point of their careers. You may infer that features going into the queue now will be merged probably no earlier than Monday. The deadline is still this coming Wednesday. Time is running quite short. The list of unresolved candidates for merge is: 1. Flow Monitor 2. MPI-Based Distributed Simulations 3. Nix-Vector Routing 4. WiMAX Models 5. Multi-Channels in YANS Wifi Phy 6. NetAnim Animator Support 7. Patch to Pause and Resume an Interface If you want to get one of these merged, please respond ASAP with your details to get a "position." If you feel you are blocked for some reason, please chime in so we can try to get your situation resolved. If you want to wait until ns-3.7, that is fine too; just let me know so I can update the list. Regards, -- Craig From jpelkey at gatech.edu Fri Sep 11 13:06:29 2009 From: jpelkey at gatech.edu (jpelkey@gatech.edu) Date: Fri, 11 Sep 2009 16:06:29 -0400 (EDT) Subject: [Ns-developers] Nix-vector Routing In-Reply-To: <910450257.430281252699424323.JavaMail.root@mail8.gatech.edu> Message-ID: <1533273790.431211252699589839.JavaMail.root@mail8.gatech.edu> Hello all, We have completed work on nix-vector routing, a simulation-specific routing protocol, for ns-3. This on-demand routing protocol is targeted at large network topologies and has been utilized in simulators such as GTNetS and ns-2. We kindly ask for a review of the code for a hopeful merge into ns-3.6. The patch set is available here: http://codereview.appspot.com/117046 The nix-vector routing code placement has been structured after olsr and global routing. Specifically, the routing code is found under src/routing/nix-vector-routing, and helper code exists in src/helper to easily place nix-vector routing on nodes (much like olsr). The data structures used by nix-vector routing have been placed in src/common. Also, two new examples have been created for nix-vector routing to show use and functionality. First, examples/nix-simple.cc is a simple four node point-to-point topology utilized to show how nix-vector routing is setup on the nodes (again, much like olsr). Next, examples/nms-p2p-nix.cc is a very large script which generates campus topologies of arbitrarily large size. This script can be used as a solid performance test. Finally, though much of the code is new, a few modifications of existing code were made. The choice for placement of nix-vectors has been packet-metadata. Initially, tags were attempted for use in nix-vector routing; however, it was determined that the nix-vectors were too large for tags. Therefore, a nix-vector smart-pointer has been placed in packet-metadata. Mathieu, I know this affects your code directly, so please let us know if this is an issue. We feel that packet-metadata is an appropriate place for the nix-vector, and we haven't come up with a better alternative. Also, Tom has raised some questions and concerns about nix-vector routing in an e-mail exchange, which I will share below, because I feel that many of you might have similar questions. > What subset of link types does it work with? I have tested nix-vector with p2p and csma links. Specifically, I modified examples "first" and "second" to use nix-vector routing. Both worked. I have also tested nix-vector with p2p links considerably with a campus network topology and over 40,000 nodes. Regarding wireless links, mobility presents a problem for what I have now in nix-vector routing. I believe it will work in some cases, for example third.cc works with nix-vector routing. > What happens when it encounters a link type for which Nix vector is not supported? Currently, we are taking the approach of global routing and allowing nix-vectors to be run on all link types. It is likely the case that this will work fine. In the case of wireless mobility however, this could present a problem, so we've documented nix-vector routing to inform the user that this should be used on wired (p2p,csma) links. > How many (which ones?) of our example programs can be successfully converted to Nix vector? I converted first and second easily to nix-vector. It is done in the same manner as olsr in simple-point-to-point-olsr, and should be extendable to most of the examples. I also have a fairly large example for nix-vector routing using p2p links (the campus network, nms). The script allows the creation of arbitrarily large topologies. Thank you! -- Josh Pelkey PhD Student, Georgia Tech From craigdo at ee.washington.edu Fri Sep 11 16:16:51 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 11 Sep 2009 16:16:51 -0700 Subject: [Ns-developers] Ns-3 Nix-vector Routing Message-ID: This probably didn't make it to the lists ... > -----Original Message----- > From: craigdo at gmail.com [mailto:craigdo at gmail.com] > Sent: Friday, September 11, 2009 3:38 PM > To: joshpelkey at gmail.com; ns-3-reviews at googlegroups.com > Subject: Ns-3 Nix-vector Routing > > Took a quick look at this before starting other business. > > > http://codereview.appspot.com/117046/diff/1/5 > File examples/nix-simple.cc (right): > > http://codereview.appspot.com/117046/diff/1/5#newcode67 > Line 67: Ipv4StaticRoutingHelper staticRouting; > Why have nixHelper, and staticRouting? It seems clearer to list.Add > staticRouting and nixRouting. > > http://codereview.appspot.com/117046/diff/1/8 > File src/common/nix-vector.cc (right): > > http://codereview.appspot.com/117046/diff/1/8#newcode168 > Line 168: if (numberOfBits > 32) > Coding standard says to add braces even if single statement > > http://codereview.appspot.com/117046/diff/1/8#newcode306 > Line 306: do > I'm curious why this isn't a for loop. That would seem more natural. > What happens if this list is empty? Can it ever be? > > http://codereview.appspot.com/117046/diff/1/8#newcode312 > Line 312: if (m_totalBitSize == 32) > Coding standard says use {}. Many more instances follow this one. > > http://codereview.appspot.com/117046/diff/1/8#newcode342 > Line 342: // of bits needed (essentailly, log2(numberOfNeighbors-1) > essentially > > http://codereview.appspot.com/117046/diff/1/8#newcode404 > Line 404: } > It would be nice to see some unit tests for this. > > http://codereview.appspot.com/117046/diff/1/10 > File src/common/packet-metadata.cc (right): > > http://codereview.appspot.com/117046/diff/1/10#newcode1201 > Line 1201: PacketMetadata::SetNixVector (Ptr nixVector) > I'm a bit concerned about this. PacketMetadata is generic. We are > adding a strongly typed pointer to this generic object to support Nix > vectors. What happens if I want to do something a little > different. Do > I add a NickVector pointer to PacketMetadata? How about a > NackVector to > the PacketMetadata later on. Why isn't this generic? Does this point > to a weakness in PacketMetadata that needs to be addressed? > > http://codereview.appspot.com/117046/diff/1/12 > File src/common/packet.cc (right): > > http://codereview.appspot.com/117046/diff/1/12#newcode214 > Line 214: Packet::SetNixVector (Ptr nixVector) > Again, I'm concerned about this kind of specific method in a generic > packet. What happens if I want to add other things like this? Packet > explodes with methods to SetNickVector or SetNackVector, etc? Won't > this lead to the dreaded fragile base class? > > http://codereview.appspot.com/117046/diff/1/18 > File > src/routing/nix-vector-routing/ipv4-nix-vector-routing.cc (right): > > http://codereview.appspot.com/117046/diff/1/18#newcode116 > Line 116: if (BuildNixVector (parentVector, source->GetId (), > destNode->GetId (), nixVector)) > Coding standard says use {} > > Other instances below. > > http://codereview.appspot.com/117046/diff/1/19 > File src/routing/nix-vector-routing/ipv4-nix-vector-routing.h (right): > > http://codereview.appspot.com/117046/diff/1/19#newcode41 > Line 41: Ipv4NixVectorRouting (); > Needs Doxygen > > http://codereview.appspot.com/117046 > From jpelkey at gatech.edu Fri Sep 11 19:16:43 2009 From: jpelkey at gatech.edu (jpelkey@gatech.edu) Date: Fri, 11 Sep 2009 22:16:43 -0400 (EDT) Subject: [Ns-developers] ns-3 NetAnim Interface In-Reply-To: <171759143.475081252721791674.JavaMail.root@mail8.gatech.edu> Message-ID: <301517105.475111252721803275.JavaMail.root@mail8.gatech.edu> Hi all, We have published a patch set for the net-anim interface in ns-3, http://codereview.appspot.com/117051. We kindly ask for any reviews, questions, comments, or concerns before a merge into (hopefully) ns-3.6. The interface allows the user to generate animation text files for use with the NetAnim GUI, which is separate from this patch and described in more detail below. Currently, the net-anim interface only generates animation text files for point-to-point links. If the animation interface is attempted for other link types, the user is presented with an error message. Two example files have been created, test-dumbbell.cc and test-grid.cc, to show the functionality and use of the animation interface. Future work includes adding support for different link types including CSMA and wireless. Mentioned above, the NetAnim GUI is separate from this patch. We have decided that this portion should be downloaded separately from ns-3, because it must be built with qt4 and make. The user is directed to this page for installation instructions of the NetAnim GUI: http://www.nsnam.org/wiki/index.php/NetAnim In the future, it may be desirable to wrap this into ns-3-allinone; however, for now we feel the animation interface could be merged, while the NetAnim GUI is downloaded separately. Thanks! -- Josh Pelkey PhD Student, Georgia Tech From boyko at iitp.ru Sat Sep 12 03:35:08 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Sat, 12 Sep 2009 14:35:08 +0400 Subject: [Ns-developers] Development of new routing protocol In-Reply-To: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> References: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> Message-ID: Hi, Egemen, On Thu, 10 Sep 2009 20:39:42 -0500 Egemen Cetinkaya wrote: > We are wondering if anyone is developing AODV, DSR, DSDV >for ns-3? > > I saw couple of threads once I Googled AODV and ns-3, >but wanted to make sure that if we are intending to develop new protocol, >we are not going to duplicate the efforts. We have finished AODV implementation recently, please find more info here: http://mailman.isi.edu/pipermail/ns-developers/2009-September/006497.html > > Also if AODV is in the pipe, what's the next routing >protocol that user's > would like to see most? Personally I'd like to: 0) encourage you to review and test our AODV implementation 1) see OLSR working, it is implemented but seems to be broken by IP routing rework of ns-3.5. 2) see multicast AODV (MAODV) implemented 3) also SMF would be great, though it is not routing 4) DYMO, but I guess this idea is already popular 5) NHDP & OLSRv2, but ask PacketBB authors first Good luck, Pavel From gjcarneiro at gmail.com Sat Sep 12 03:46:32 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Sat, 12 Sep 2009 11:46:32 +0100 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> Message-ID: 2009/9/11 > Hi All, > > We have three features queued up for addition into ns-3.6 at this time. > These features will be serialized and merged into ns-3-dev over the next > couple of days. > > 1. Testing and Validation Framework > 2. PacketBB (RFC 5444) > 3. 802.11s Mesh Model > > I will start the process on these features this afternoon; and if all goes > well these should all be part of the new and improved ns-3-dev by Monday. > > If everyone could take a look as these features appear and exercise them as > much as possible I would be grateful beyond words. You may even win the > weekly ns-3.6 release door prize if you find problems. Some say that > receiving this award was the high point of their careers. > > You may infer that features going into the queue now will be merged > probably > no earlier than Monday. The deadline is still this coming Wednesday. Time > is running quite short. > > The list of unresolved candidates for merge is: > > 1. Flow Monitor > Flow Monitor is blocked by lack of further responses from other NS developers... I don't think there is anything I can do until then. Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From sgros at zemris.fer.hr Sat Sep 12 03:17:47 2009 From: sgros at zemris.fer.hr (Stjepan Gros) Date: Sat, 12 Sep 2009 12:17:47 +0200 Subject: [Ns-developers] Compiling ns-3.5 on Fedora 11 Message-ID: <1252750667.14492.8.camel@fedora> Hi! I'm trying to compile ns-3.5 on 64-bit Fedora 11. When I run build.py immediatelly after unpacking the archive, the compilation fails with the following error: [614/702] cxx: build/debug/bindings/python/ns3_module_csma.cc -> build/debug/bindings/python/ns3_module_csma_3.o In file included from /usr/include/python2.6/pyconfig.h:6, from /usr/include/python2.6/Python.h:8, from debug/bindings/python/ns3module.h:3, from ../bindings/python/ns3module_helpers.cc:2: /usr/include/python2.6/pyconfig-64.h:1022:1: error: "_POSIX_C_SOURCE" redefined In file included from /usr/include/stdint.h:26, from debug/ns3/ref-count-base.h:26, from ../bindings/python/ns3module_helpers.cc:1: /usr/include/features.h:158:1: error: this is the location of the previous definition In file included from /usr/include/python2.6/pyconfig.h:6, from /usr/include/python2.6/Python.h:8, from debug/bindings/python/ns3module.h:3, from ../bindings/python/ns3module_helpers.cc:2: /usr/include/python2.6/pyconfig-64.h:1031:1: error: "_XOPEN_SOURCE" redefined In file included from /usr/include/stdint.h:26, from debug/ns3/ref-count-base.h:26, from ../bindings/python/ns3module_helpers.cc:1: /usr/include/features.h:160:1: error: this is the location of the previous definition Waf: Leaving directory `/opt/simulators/ns-allinone-3.5/ns-3.5/build' Build failed -> task failed (err #1): {task: cxx ns3module_helpers.cc -> ns3module_helpers_3.o} Traceback (most recent call last): File "./build.py", line 117, in sys.exit(main(sys.argv)) File "./build.py", line 108, in main build_ns3(config) File "./build.py", line 56, in build_ns3 run_command(["python", "waf"]) File "/opt/simulators/ns-allinone-3.5/util.py", line 24, in run_command raise CommandError("Command %r exited with code %i" % (argv, retval)) util.CommandError: Command ['python', 'waf'] exited with code 1 Which turns out to be the consequence of including stdint.h _before_ pyconfig.h. But I don't know how to reverse those two. I also noticed that the compilation of the file nsc-0.5.0/globaliser/handle_global.cc fails reporting undefined uint32_t type. This is resolved by including stdint.h in that file. But, after I fixed that, there is another problem, probably related to SCons build system that I don't understand, so I can not fix it. The following is the error output: gcc " " - f P I C " " " " - D _ _ A S S E M B L 1 Y _ _ - f P I C " " -Ilinux-2.6.18/include -Ilinux-2.6.18/include/asm/mach-default -Isim -Ilinux-2.6.18/nsc -Ilinux-2.6.18/override -c -o linux-2.6.18/arch/x86_64/lib/csum-copy.o linux-2.6.18/arch/x86_64/lib/csum-copy.S gcc: : No such file or directory gcc: f: No such file or directory gcc: P: No such file or directory gcc: I: No such file or directory gcc: C: No such file or directory gcc: : No such file or directory gcc: : No such file or directory gcc: D: No such file or directory gcc: _: No such file or directory gcc: _: No such file or directory gcc: A: No such file or directory gcc: S: No such file or directory gcc: S: No such file or directory gcc: E: No such file or directory gcc: M: No such file or directory gcc: B: No such file or directory gcc: L: No such file or directory gcc: 1: No such file or directory gcc: Y: No such file or directory gcc: _: No such file or directory gcc: _: No such file or directory gcc: f: No such file or directory gcc: P: No such file or directory gcc: I: No such file or directory gcc: C: No such file or directory gcc: : No such file or directory gcc: cannot specify -o with -c or -S with multiple files This doesn't stop the compilation process. But it eventually stops with the first error. I'm using the following program versions: python-2.6-9.fc11.x86_64 gcc 4.4.1 Stjepan From sergio at larces.uece.br Fri Sep 11 14:06:35 2009 From: sergio at larces.uece.br (Sergio Luis O. B. Correia) Date: Fri, 11 Sep 2009 18:06:35 -0300 Subject: [Ns-developers] Development of new routing protocol In-Reply-To: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> References: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> Message-ID: <430c4fa50909111406w6248e7f8x8ca52bbd54af9bb1@mail.gmail.com> Hello, On Thu, Sep 10, 2009 at 10:39 PM, Egemen Cetinkaya wrote: > Hi, > > We are wondering if anyone is developing AODV, DSR, DSDV for ns-3? > > I saw couple of threads once I Googled AODV and ns-3, but wanted to make > sure that if we are intending to develop new protocol, we are not going to > duplicate the efforts. > > Also if AODV is in the pipe, what's the next routing protocol that user's > would like to see most? > maybe OLSR and DYMO? sergio > Thanks, > > Egemen Cetinkaya > -- Computer Networks and Security Laboratory (LARCES) State University of Ceara (UECE/Brazil) From securityfusion at gmail.com Fri Sep 11 11:26:51 2009 From: securityfusion at gmail.com (Richardson Lima) Date: Fri, 11 Sep 2009 15:26:51 -0300 Subject: [Ns-developers] [ AntNet ] Download Ns2.33-Antnet1.0 by Richardson Lima Message-ID: <3a835c350909111126s6a90d01cn99366044ecbed3b6@mail.gmail.com> All, New link for download !!! http://antnet.wordpress.com *Software implementations of AntNet posted by Gianni Di Caro* http://www.idsia.ch/~gianni/antnet.html Lavina Jain made an implementation of AntNet for NS-2 (that can be also downloaded here). Starting from Jain?s code, *Richardson Lima* has released a revised and updated version of AntNet for NS-2.33. Since I?m not an NS-2 user, I haven?t checked these implementations, but I guess the Lima?s implementation can be used as a good starting point. If you plan to use Lima?s code, please feel free to contact me to check/improve the quality of the implementation. *Download Ns2.33-Antnet1.0 by Richardson Lima * http://www.foxylinux.com/ns2-33_AND_antnet1.0_by_RichardsonLima.tar.gz [] ' s -- -- ----------------------------------------------- Richardson Lima *http://antnet.wordpress.com* http://richardsonlima.foxylinux.com *www.foxylinux.com ( Because nobody was born with Linux knowledge! )* http://securityfusion.sourceforge.net (Security Fusion intrusion detection system) Position: Security System Administrator Location: Networking and Telecommuncations Research Group Federal University of Pernambuco Informatics Center, Brazil P.O. Box: 7851, ZIP: 50732-970 Phone: +55-81-2126-8954 Fax:+55-81-2126-8955 Gsm Mobile: +55 81 88725173 Este e-mail ? confidencial e de uso exclusivo do destinat?rio. Seu conte?do n?o deve ser revelado a terceiros. Caso voc? n?o seja o destinat?rio, por favor notifique o remetente e elimine esta mensagem imediatamente. Alerto que esta mensagem transitou por rede p?blica de comunica??o, estando, portanto, sujeita aos riscos inerentes a essa forma de comunica??o. This e-mail is private and confidential, and of exclusive use of the addressee only. Its contents should not be revealed to third parties. If you are not the intended addressee, please notify the sender and promptly delete this message. It should be advised that this correspondence has been transmitted through a public communication channel, being, therefore, subject to the inherent risks of such kind of communication. From tomh at tomh.org Sat Sep 12 09:13:16 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 12 Sep 2009 09:13:16 -0700 Subject: [Ns-developers] Compiling ns-3.5 on Fedora 11 In-Reply-To: <1252750667.14492.8.camel@fedora> References: <1252750667.14492.8.camel@fedora> Message-ID: <4AABC89C.801@tomh.org> Stjepan Gros wrote: > Hi! > > I'm trying to compile ns-3.5 on 64-bit Fedora 11. When I run build.py > immediatelly after unpacking the archive, the compilation fails with the > following error: > > [614/702] cxx: build/debug/bindings/python/ns3_module_csma.cc -> > build/debug/bindings/python/ns3_module_csma_3.o > In file included from /usr/include/python2.6/pyconfig.h:6, > from /usr/include/python2.6/Python.h:8, > from debug/bindings/python/ns3module.h:3, > from ../bindings/python/ns3module_helpers.cc:2: > /usr/include/python2.6/pyconfig-64.h:1022:1: error: "_POSIX_C_SOURCE" > redefined > In file included from /usr/include/stdint.h:26, > from debug/ns3/ref-count-base.h:26, > from ../bindings/python/ns3module_helpers.cc:1: > /usr/include/features.h:158:1: error: this is the location of the > previous definition > In file included from /usr/include/python2.6/pyconfig.h:6, > from /usr/include/python2.6/Python.h:8, > from debug/bindings/python/ns3module.h:3, > from ../bindings/python/ns3module_helpers.cc:2: > /usr/include/python2.6/pyconfig-64.h:1031:1: error: "_XOPEN_SOURCE" > redefined > In file included from /usr/include/stdint.h:26, > from debug/ns3/ref-count-base.h:26, > from ../bindings/python/ns3module_helpers.cc:1: > /usr/include/features.h:160:1: error: this is the location of the > previous definition > Waf: Leaving directory `/opt/simulators/ns-allinone-3.5/ns-3.5/build' > Build failed > -> task failed (err #1): > {task: cxx ns3module_helpers.cc -> ns3module_helpers_3.o} > Traceback (most recent call last): > File "./build.py", line 117, in > sys.exit(main(sys.argv)) > File "./build.py", line 108, in main > build_ns3(config) > File "./build.py", line 56, in build_ns3 > run_command(["python", "waf"]) > File "/opt/simulators/ns-allinone-3.5/util.py", line 24, in > run_command > raise CommandError("Command %r exited with code %i" % (argv, > retval)) > util.CommandError: Command ['python', 'waf'] exited with code 1 > > Which turns out to be the consequence of including stdint.h _before_ > pyconfig.h. But I don't know how to reverse those two. > > > I also noticed that the compilation of the file > nsc-0.5.0/globaliser/handle_global.cc fails reporting undefined uint32_t > type. This is resolved by including stdint.h in that file. But, after I > fixed that, there is another problem, probably related to SCons build > system that I don't understand, so I can not fix it. The following is > the error output: > > gcc " " - f P I C " " " " - D _ _ A S S E M B L 1 Y _ _ - f P I C " " > -Ilinux-2.6.18/include -Ilinux-2.6.18/include/asm/mach-default -Isim > -Ilinux-2.6.18/nsc -Ilinux-2.6.18/override -c -o > linux-2.6.18/arch/x86_64/lib/csum-copy.o > linux-2.6.18/arch/x86_64/lib/csum-copy.S > gcc: : No such file or directory > gcc: f: No such file or directory > gcc: P: No such file or directory > gcc: I: No such file or directory > gcc: C: No such file or directory > gcc: : No such file or directory > gcc: : No such file or directory > gcc: D: No such file or directory > gcc: _: No such file or directory > gcc: _: No such file or directory > gcc: A: No such file or directory > gcc: S: No such file or directory > gcc: S: No such file or directory > gcc: E: No such file or directory > gcc: M: No such file or directory > gcc: B: No such file or directory > gcc: L: No such file or directory > gcc: 1: No such file or directory > gcc: Y: No such file or directory > gcc: _: No such file or directory > gcc: _: No such file or directory > gcc: f: No such file or directory > gcc: P: No such file or directory > gcc: I: No such file or directory > gcc: C: No such file or directory > gcc: : No such file or directory > gcc: cannot specify -o with -c or -S with multiple files > > This doesn't stop the compilation process. But it eventually stops with > the first error. > > I'm using the following program versions: > > python-2.6-9.fc11.x86_64 > gcc 4.4.1 > > Stjepan > You need to patch ns-3.5 with this patch for Fedora Core 11: http://code.nsnam.org/ns-3-dev/rev/e33a677e8864 I will put together a suggested list of changesets for a maintenance update of ns-3.5 in the next few days. From tomh at tomh.org Sat Sep 12 21:48:33 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 12 Sep 2009 21:48:33 -0700 Subject: [Ns-developers] Compiling ns-3.5 on Fedora 11 In-Reply-To: <4AABC89C.801@tomh.org> References: <1252750667.14492.8.camel@fedora> <4AABC89C.801@tomh.org> Message-ID: <4AAC79A1.10401@tomh.org> >> >> I also noticed that the compilation of the file >> nsc-0.5.0/globaliser/handle_global.cc fails reporting undefined uint32_t >> type. This is resolved by including stdint.h in that file. But, after I >> fixed that, there is another problem, probably related to SCons build >> system that I don't understand, so I can not fix it. The following is >> the error output: >> >> This doesn't stop the compilation process. But it eventually stops with >> the first error. >> >> I'm using the following program versions: >> >> python-2.6-9.fc11.x86_64 >> gcc 4.4.1 >> >> Stjepan >> The attached patch (to apply to nsc-0.5.0) should clean up your nsc build problems. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nsc.patch Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090912/fa40c0b6/nsc.ksh From mathieu.lacage at sophia.inria.fr Sun Sep 13 17:35:29 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Sun, 13 Sep 2009 17:35:29 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200909140035.n8E0ZTT4007439@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/103 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Sun Sep 13 17:37:28 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Sun, 13 Sep 2009 17:37:28 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200909140037.n8E0bSeO007447@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/145 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_16 shell_17 shell_18 sincerely, -The Buildbot From tomh at tomh.org Sun Sep 13 21:06:27 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 13 Sep 2009 21:06:27 -0700 Subject: [Ns-developers] ns-3.5.1 release? Message-ID: <4AADC143.8060305@tomh.org> I'd like to propose an ns-3.5.1 release that includes the following changesets since ns-3.5. I suggest to post an ns-allinone-3.5.1 release and an ns-3.5-to-ns-3.5.1.patch. Regarding nsc, it seems like we did not include a released version of nsc for the ns-3.5 release. If nsc can make a maintenance release now, we can include that; otherwise, I suggest that we just include the tip of nsc's development tree, to obtain the gcc-4.4 fixes. Bug fixes: --------- fdf71375766a: Bug 628: Virtual Net Device's DoDispose doesn't clean up properly; patch by Antti M?kel?. 7defe7a99e9c: fix bug preventing the sending of packets to a local IP address (bug 632) 258cf77942bc: emu device shouldn't be adding an FCS 7555c9a0564b: bug 627: Jakes Propagation Loss Model doesn't properly calculate signal loss f17f12944235: Bug 625: Wrong calculation of GetAccessGrantStart in DcfManager. 02bf728f7e39: bug 381: Wifi crashes on shutdown 6cd5056a8fe0: Fix first.py example 637b9cacd0b5: bug 642: allow multiple InternetStackHelpers to be instantiated 6e048d6486d8: Implement UdpSocketImpl::Close () 60cd412fa3dd: fix for bug 650 (PacketSocket Close() e33a677e8864: Reorder the #includes in ns3module_helpers.cc to solve Fedora 11 compilation error b251fb79becb: bug 639: Buffer::CopyData is buggy. 3fdb8f60a863: bug 654: avoid segfault with ConfigStore loading fef6ccee5897: Fixed erroneous first return of Normal Variable 5e4fb3918879: Fixed WifiMacHeader Print Control Characters bug 661 (bug 643 patch could also be included in this list, if it is pushed soon) Documentation (manual, doxygen) changesets: ------------- 36b78cddce4d 6dc56539a891 b57d5b1fe68e 04a9a7e9a624 3d08aef4a581 ba5d6d52be7e From tomh at tomh.org Sun Sep 13 23:08:54 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 13 Sep 2009 23:08:54 -0700 Subject: [Ns-developers] Proposing to merge FlowMonitor in ns-3-dev In-Reply-To: References: Message-ID: <4AADDDF6.2070609@tomh.org> Gustavo Carneiro wrote: > A reminder that I am still interested in merging FlowMonitor. The code I am > working on is at: http://code.nsnam.org/gjc/ns-3-dev-flowmon/ > > Below a summary of the last email exchanges on the subject. > > Mathieu once commented that: > >> sorry for taking so long to look at this: I don't have many comments >> other than that it is missing needed api documentation and that it's >> looks pretty cool :) >> >> The histogram class probably should go in either src/contrib or >> src/common directly. >> >> > I will work on the documentation front. > > I also don't mind about moving the histogram class. Any other opinions on > this issue? If we had (or wanted to start) a statistics module, it could go there-- absent a statistics module, src/common seems to be as good as any home for it. Or src/contrib for the moment. > > Tom said: > >> Hi Gustavo, I also looked at this yesterday and would like to propose to >> get it merged this release cycle. I wonder whether there is common >> functionality to what Qasim is working on for a conntracking module; maybe >> he can review and comment. >> > > I looked at NetFilter code but could not see, at least right away, what > could be reused from connection tracking. However, this is mostly > implementation detail and does not impact the API, so that it would still be > possible to do it in the future, in case I am mistaken. Agree. > > Tom said also: > >> It seemed to me that we could move the core components of this to >> src/common, and the ipv4-specific to internet-stack. >> > > What do you mean by "core components"? All of the FlowMonitor core > components, like classes FlowMonitor, FlowProbe, FlowClassifier, Histogram? > Not just Histogram? But then the flow-monitor module disappears, dissolving > into src/common and src/internet-stack, is that what you mean? Yes. > Well, I > guess I am OK, with it, although I was expecting a kind of "probation" > period where a module proves its usefulness to the ns-3 users by spending > some time in src/contrib. I would be fine with merging it to src/contrib if you would like a probation period with it. In general, this is the kind of additional simulator support module that I'd like to see more of, so I envision that I would vote in the future to move it from src/contrib into the main tree; hence I had recommended to just move it now. However, I do not mind if it spends a cycle in contrib/ while it is evaluated. One area that I had some question is how it is expected to be extended to possibly other transport protocols; right now it seems to only handle TCP and UDP. > > About this last issue, Mathieu said: > >> If you do this, we will need to improve the doxygen for these classes. >> If they stay as-is without additional documentation, they should be >> merged in src/contrib. >> > > Well, I think it should be documented regardless. > > Next Tom also said: > >> You could keep it in src/contrib for now if you want to allow it to draw >> comments for a while. >> > > > Summary of open issues: > > 1. Need more doxygen for FlowMonitor. I will work on this. > 2. Need to approve the Ipv4L3Protocol traced source changes. I have > received some comments, but no clear approval yet; I am fine with them in general. In the ns-3-reviews thread, when discussing netfilter alignment, you mentioned: "it is best to place the trace sources right after the netfilter hooks have run and indicated their verdict, and only if the packet is allowed to be processed." I agree with what you suggested. However, once Netfilter hooks are merged there may need to be some movement of these trace hooks (particularly SendOutgoing). The Netfilter hooks will be at a place where IP headers are in the packet so hopefully there will be an opportunity to have a header-less packet around in those methods so that we don't have to then remove the header again before hitting the trace source. > 3. Decide whether to keep flow-monitor as a src/contrib module or > dissolve it into src/common and src/internet-stack. Looking at it tonight, it seems that the lack of example programs, documentation and test cases might make it a src/contrib candidate for this release. So in summary, +1 on trying to merge this into ns-3.6. src/contrib might be the best location for this cycle in light of the above. Tom From gjcarneiro at gmail.com Mon Sep 14 03:18:30 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 14 Sep 2009 11:18:30 +0100 Subject: [Ns-developers] Proposing to merge FlowMonitor in ns-3-dev In-Reply-To: <4AADDDF6.2070609@tomh.org> References: <4AADDDF6.2070609@tomh.org> Message-ID: 2009/9/14 Tom Henderson > Gustavo Carneiro wrote: > >> A reminder that I am still interested in merging FlowMonitor. The code I >> am >> working on is at: http://code.nsnam.org/gjc/ns-3-dev-flowmon/ >> >> Below a summary of the last email exchanges on the subject. >> >> Mathieu once commented that: >> >> sorry for taking so long to look at this: I don't have many comments >>> other than that it is missing needed api documentation and that it's >>> looks pretty cool :) >>> >>> The histogram class probably should go in either src/contrib or >>> src/common directly. >>> >>> >>> I will work on the documentation front. >> >> I also don't mind about moving the histogram class. Any other opinions on >> this issue? >> > > If we had (or wanted to start) a statistics module, it could go there-- > absent a statistics module, src/common seems to be as good as any home for > it. Or src/contrib for the moment. There is a kind of statistics module, src/contrib/stats, but it has a different style from the Flow Monitor code: moderate use of templates, deep class inheritance trees. > > > >> Tom said: >> >> Hi Gustavo, I also looked at this yesterday and would like to propose to >>> get it merged this release cycle. I wonder whether there is common >>> functionality to what Qasim is working on for a conntracking module; >>> maybe >>> he can review and comment. >>> >>> >> I looked at NetFilter code but could not see, at least right away, what >> could be reused from connection tracking. However, this is mostly >> implementation detail and does not impact the API, so that it would still >> be >> possible to do it in the future, in case I am mistaken. >> > > Agree. > > >> Tom said also: >> >> It seemed to me that we could move the core components of this to >>> src/common, and the ipv4-specific to internet-stack. >>> >>> >> What do you mean by "core components"? All of the FlowMonitor core >> components, like classes FlowMonitor, FlowProbe, FlowClassifier, >> Histogram? >> Not just Histogram? But then the flow-monitor module disappears, >> dissolving >> into src/common and src/internet-stack, is that what you mean? >> > > Yes. > > Well, I >> guess I am OK, with it, although I was expecting a kind of "probation" >> period where a module proves its usefulness to the ns-3 users by spending >> some time in src/contrib. >> > > I would be fine with merging it to src/contrib if you would like a > probation period with it. > > In general, this is the kind of additional simulator support module that > I'd like to see more of, so I envision that I would vote in the future to > move it from src/contrib into the main tree; hence I had recommended to just > move it now. However, I do not mind if it spends a cycle in contrib/ while > it is evaluated. > > One area that I had some question is how it is expected to be extended to > possibly other transport protocols; right now it seems to only handle TCP > and UDP. > It's easy, just add some lines of code to Ipv4FlowClassifier::Classify. It is not possible to make the code generic because the transport protocol Header classes do no have a common abstract base class that could be used to get the source/dest ports. > > >> About this last issue, Mathieu said: >> >> If you do this, we will need to improve the doxygen for these classes. >>> If they stay as-is without additional documentation, they should be >>> merged in src/contrib. >>> >>> >> Well, I think it should be documented regardless. >> >> Next Tom also said: >> >> You could keep it in src/contrib for now if you want to allow it to draw >>> comments for a while. >>> >>> >> >> Summary of open issues: >> >> 1. Need more doxygen for FlowMonitor. I will work on this. >> 2. Need to approve the Ipv4L3Protocol traced source changes. I have >> received some comments, but no clear approval yet; >> > > I am fine with them in general. In the ns-3-reviews thread, when > discussing netfilter alignment, you mentioned: "it is best to place the > trace sources right after the netfilter hooks have run and indicated their > verdict, and only if the packet is allowed to be processed." > > I agree with what you suggested. However, once Netfilter hooks are merged > there may need to be some movement of these trace hooks (particularly > SendOutgoing). The Netfilter hooks will be at a place where IP headers are > in the packet so hopefully there will be an opportunity to have a > header-less packet around in those methods so that we don't have to then > remove the header again before hitting the trace source. > > > 3. Decide whether to keep flow-monitor as a src/contrib module or >> dissolve it into src/common and src/internet-stack. >> > > Looking at it tonight, it seems that the lack of example programs, > documentation and test cases might make it a src/contrib candidate for this > release. > To clarify: - Histogram has unit tests (at the end of histogram.cc); - There is no regression test; though I could find time to make one, I guess; - There is doxygen API docs, but no tutorial. I have an entire paper written on it, though, including a short tutorial section. Too bad I can't make it freely available due to conference copyright issues :-( - There is an example: I modified the simple-global-routing example to allow Flow Monitor via command-line option. http://code.nsnam.org/gjc/ns-3-dev-flowmon/rev/6dfb327dcabb > > So in summary, +1 on trying to merge this into ns-3.6. src/contrib might > be the best location for this cycle in light of the above. > > Tom > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Mon Sep 14 18:58:16 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 14 Sep 2009 18:58:16 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200909150158.n8F1wGoK019196@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/157 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From craigdo at ee.washington.edu Tue Sep 15 00:43:59 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 15 Sep 2009 00:43:59 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> Message-ID: <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> Hi All, Good (very early) morning from your friendly neighborhood ns-3.6 release manager. The following new features have now been merged into ns-3-dev: 1. Testing and Validation Framework 2. PacketBB (RFC 5444) 3. 802.11s Mesh Model The merge queue is now empty. Now is your chance to get your new feature submission integrated into ns-3.6! The cutoff date is close of business (as you can see, I close business around Midnight) on Wednesday. The list of unresolved candidates for merge is: 1. Flow Monitor 2. Nix-Vector Routing 3. WiMAX Models 4. Multi-Channels in YANS Wifi Phy 5. NetAnim Animator Support 6. Patch to Pause and Resume an Interface Who wants to go next? Time is running very short ... Regards, -- Craig From mathieu.lacage at sophia.inria.fr Tue Sep 15 01:07:28 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 10:07:28 +0200 Subject: [Ns-developers] ns-3.5.1 release? In-Reply-To: <4AADC143.8060305@tomh.org> References: <4AADC143.8060305@tomh.org> Message-ID: <1253002048.14583.10.camel@diese.inria.fr> hi tom, I will try to put together a branch with your suggested fixes tomorrow. Mathieu On Sun, 2009-09-13 at 21:06 -0700, Tom Henderson wrote: > I'd like to propose an ns-3.5.1 release that includes the following > changesets since ns-3.5. I suggest to post an ns-allinone-3.5.1 release > and an ns-3.5-to-ns-3.5.1.patch. > > Regarding nsc, it seems like we did not include a released version of > nsc for the ns-3.5 release. If nsc can make a maintenance release now, > we can include that; otherwise, I suggest that we just include the tip > of nsc's development tree, to obtain the gcc-4.4 fixes. > > Bug fixes: > --------- > > fdf71375766a: Bug 628: Virtual Net Device's DoDispose doesn't clean up > properly; patch by Antti M?kel?. > > 7defe7a99e9c: fix bug preventing the sending of packets to a local IP > address (bug 632) > > 258cf77942bc: emu device shouldn't be adding an FCS > > 7555c9a0564b: bug 627: Jakes Propagation Loss Model doesn't properly > calculate signal loss > > f17f12944235: Bug 625: Wrong calculation of GetAccessGrantStart in > DcfManager. > > 02bf728f7e39: bug 381: Wifi crashes on shutdown > > 6cd5056a8fe0: Fix first.py example > > 637b9cacd0b5: bug 642: allow multiple InternetStackHelpers to be > instantiated > > 6e048d6486d8: Implement UdpSocketImpl::Close () > > 60cd412fa3dd: fix for bug 650 (PacketSocket Close() > > e33a677e8864: Reorder the #includes in ns3module_helpers.cc to solve > Fedora 11 compilation error > > b251fb79becb: bug 639: Buffer::CopyData is buggy. > > 3fdb8f60a863: bug 654: avoid segfault with ConfigStore loading > > fef6ccee5897: Fixed erroneous first return of Normal Variable > > 5e4fb3918879: Fixed WifiMacHeader Print Control Characters bug 661 > > (bug 643 patch could also be included in this list, if it is pushed soon) > > Documentation (manual, doxygen) changesets: > ------------- > > 36b78cddce4d > 6dc56539a891 > b57d5b1fe68e > 04a9a7e9a624 > 3d08aef4a581 > ba5d6d52be7e > From mathieu.lacage at sophia.inria.fr Tue Sep 15 01:22:35 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 10:22:35 +0200 Subject: [Ns-developers] 802.11s mesh model review In-Reply-To: <4E32E6229DF945DB9B1C28F76A56DAF3@CRAIGVAIO> References: <4A4F4B8602000083000479CF@gwia1.ipfw.edu> <200907051312.34742.boyko@iitp.ru> <4AA89B5C.5020206@tomh.org> <200909101139.38682.boyko@iitp.ru> <4AA91375.2010306@tomh.org> <4E32E6229DF945DB9B1C28F76A56DAF3@CRAIGVAIO> Message-ID: <1253002955.14583.13.camel@diese.inria.fr> On Thu, 2009-09-10 at 13:03 -0700, craigdo at ee.washington.edu wrote: > Anyway, I don't think anyone is going to hold up your submission because you > used ///, but don't be surprised if someone changes it during one of our > periodic Doxygenation sweeps through the system; and don't be surprised if > other reviewers notice it since it is inconsistent with respect to the rest > of the system. > > So, for future reference, we would like existing styles of code and > documentation to be respected when additions are made. > > However, if we are going to spend time mentioning it and writing words about > it, something to this effect should be put in the coding standard document. craig summarized the issue pretty well and I agree with his conclusions. There is nothing wrong with /// but we should strive for style consistency and I support adding in our coding style document a paragraph mentionning that /**/ is the prefered doxygen format. Mathieu From joysmilelol at yahoo.com Tue Sep 15 03:02:46 2009 From: joysmilelol at yahoo.com (joy smilelol) Date: Tue, 15 Sep 2009 10:02:46 +0000 (GMT) Subject: [Ns-developers] cancellation In-Reply-To: <1253002955.14583.13.camel@diese.inria.fr> Message-ID: <950344.87786.qm@web23807.mail.ird.yahoo.com> Dear Sir, Kindly remove my ID from the list. I am not doing NS anymore. Thank you From mathieu.lacage at sophia.inria.fr Tue Sep 15 03:48:34 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 12:48:34 +0200 Subject: [Ns-developers] Nix-vector Routing In-Reply-To: <1533273790.431211252699589839.JavaMail.root@mail8.gatech.edu> References: <1533273790.431211252699589839.JavaMail.root@mail8.gatech.edu> Message-ID: <1253011714.14583.32.camel@diese.inria.fr> hi josh, On Fri, 2009-09-11 at 16:06 -0400, jpelkey at gatech.edu wrote: > Finally, though much of the code is new, a few modifications of > existing code were made. The choice for placement of nix-vectors has > been packet-metadata. Initially, tags were attempted for use in > nix-vector routing; however, it was determined that the nix-vectors > were too large for tags. Therefore, a nix-vector smart-pointer has > been placed in packet-metadata. Mathieu, I know this affects your > code directly, so please let us know if this is an issue. We feel > that packet-metadata is an appropriate place for the nix-vector, and > we haven't come up with a better alternative. I am not sure why you have put this in the packet metadata class. This class records information about the type of the headers and trailers which are present in a packet so, logically, it does not have much to do with a nix vector. Instead, it probably makes much more sense to move this to the Packet class itself. I think I had pointed this out to you before but I don't believe your current implementation is correct with regard to packet copies. i.e., if I call Packet::Copy, both packets will share the same underlying nix vector and if you modify the content of the nix vector in a node, the other nodes who still have a copy of that packet in their outgoing queues will see the modified nix vector, hence resulting in really weird results. The easiest way to avoid this problem would be to create a deep copy of the nix vector in Packet::Copy. That could be a potential performance problem: if you can come up with a more efficient way to making it robust, it is fine with me but if I am right about the potential problem, the current implementation cannot go in as-is. I added a couple of small comments to the issue tracker. Mathieu From vincent at clarinet.u-strasbg.fr Tue Sep 15 03:50:21 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Tue, 15 Sep 2009 12:50:21 +0200 Subject: [Ns-developers] Simulation builder GUI Message-ID: <4AAF716D.20204@clarinet.u-strasbg.fr> Hi, One of our recent trainee at university of Strasbourg, Pierre Weiss, had worked about a GUI generator of ns-3 simulations. The goal of this project is to propose an easy and intuitive way to build simulation with nodes, routers, switch, AP, ... without writting them (in C++/python) by hand (for ns-3-dev version). We think that could be very useful for users to quickly build complex topology. Pierre has accepted to continue his work in his free time. He will also propose to work on it as part of one project for his bachelor degree. Features supported: - Graphically put entity (node, group of nodes, hub, switch, router, AP) and link them (csma, point-to-point, wifi); - Possibility to have one "Emu" and "Tap" nodes. - IPv4 addressing; - Add applications (UdpEcho, ...); - Generate C++ simulation code. In the future we plan to: - Add a configuration GUI that will show attributes and information about entities; - Configuration of links and Wi-Fi stuff (rate, ...); - Add a better GUI to add applications; - Generate python code; - Load/save simulation topology in XML file; - Screenshot of the topology. The sourcecode is not yet available but you can see in attachment a screenshot of the GUI. We will release source code when at least configuration and application GUI refactoring will be done. So stay tuned As usual any feedbacks are welcomed about this project (new features, ...). Best regards, -- Sebastien Vincent University of Strasbourg -------------- next part -------------- A non-text attachment was scrubbed... Name: ns-3-generator.png Type: image/png Size: 43900 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090915/14da8c65/ns-3-generator-0001.png From monbauza at gmail.com Tue Sep 15 04:08:24 2009 From: monbauza at gmail.com (Ramon Bauza) Date: Tue, 15 Sep 2009 13:08:24 +0200 Subject: [Ns-developers] Channel switching support for Wifi Message-ID: <63e322e20909150408n11eefef8p4ef0fa8991a3ec1e@mail.gmail.com> After receiving the ok from Mathieu, I have pushed into the ns-3-dev branch the changes related to the channel switching support for Wifi. The code was reviewed in the issue http://codereview.appspot.com/96109 I have also updated the AUTHORS, RELEASE_NOTES and CHANGES.html files. The modified files are: AUTHORS CHANGES.html RELEASE_NOTES examples/wifi-ap.cc src/devices/wifi/dca-txop.cc src/devices/wifi/dca-txop.h src/devices/wifi/dcf-manager-test.cc src/devices/wifi/dcf-manager.cc src/devices/wifi/dcf-manager.h src/devices/wifi/edca-txop-n.cc src/devices/wifi/edca-txop-n.h src/devices/wifi/interference-helper.cc src/devices/wifi/interference-helper.h src/devices/wifi/mac-low.cc src/devices/wifi/mac-low.h src/devices/wifi/wifi-phy-state-helper.cc src/devices/wifi/wifi-phy-state-helper.h src/devices/wifi/wifi-phy.h src/devices/wifi/yans-wifi-phy.cc src/devices/wifi/yans-wifi-phy.h YansWifiPhy can now switch among different channels. Basically each YansWifiPhy has a private attribute m_channelNumber that identifies the channel the PHY operates on. YansWifiChannel delivers packets only between PHY with the same m_channelNumber. Channel center frequency is calculated from m_channelNumber in the standard specific way. There is a configurable channel switch delay. Some important points regarding the channel switching process in the implementation: - Channel switching cannot interrupt an ongoing transmission. When PHY is in TX state, the channel switching is postponed until the end of the current transmission. - When the PHY is in SYNC state, the channel switching causes the drop of the sync packet. - When a channel switching occurs, pending MAC transmissions (RTS, CTS, DATA and ACK) are cancelled and DcaTxop/EdcaTxop queues are flushed. - During SWITCHING state, new packets can be enqueued in DcaTxop/EdcaTxop but they won't access to the medium until the end of the channel switching. Best regards, Ramon. -- -------------------------------------------------------------------------- Ramon Bauza Ubiquitous Wireless Communications Research Laboratory Uwicore, http://www.uwicore.umh.es Signal Theory and Communications Division University Miguel Hern?ndez (Spain) Tel: +34 96522 2031 Fax: +34 96665 8903 ---------------------------------------------------------------------------- From gjcarneiro at gmail.com Tue Sep 15 05:10:55 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 15 Sep 2009 13:10:55 +0100 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> Message-ID: 2009/9/15 > > Hi All, > > Good (very early) morning from your friendly neighborhood ns-3.6 release > manager. > > The following new features have now been merged into ns-3-dev: > > 1. Testing and Validation Framework > 2. PacketBB (RFC 5444) > 3. 802.11s Mesh Model > > The merge queue is now empty. Now is your chance to get your new feature > submission integrated into ns-3.6! The cutoff date is close of business > (as > you can see, I close business around Midnight) on Wednesday. > > The list of unresolved candidates for merge is: > > 1. Flow Monitor > 2. Nix-Vector Routing > 3. WiMAX Models > 4. Multi-Channels in YANS Wifi Phy > 5. NetAnim Animator Support > 6. Patch to Pause and Resume an Interface > > Who wants to go next? Time is running very short ... > I think I am ready to merge Flow Monitor. Just to make sure I do not introduce surprising changes, I recently aligned Ipv6L3Protocol::Drop with the modifications I had done for Ipv4L3Protocol::Drop. Mathieu had already remarked earlier, in ns-3-reviews, that there is some inconsistency with Ipv4L3Protocol trace sources: Drop and the new trace sources include a separate IP header and the packet without the header, while Tx and Rx include the packet with header already added. I did not touch Tx and Rx because I do not need them, but if asked I am willing to quickly align Tx and Rx with Drop, i.e. pass the header separated from the packet payload. If none of the above is of great concern, I'd like to request to merge Flow Monitor anyway. It'd be a pity to miss the 3.6 boat... Thanks, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Tue Sep 15 05:28:52 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 14:28:52 +0200 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> Message-ID: <1253017732.14583.70.camel@diese.inria.fr> On Tue, 2009-09-15 at 13:10 +0100, Gustavo Carneiro wrote: > Mathieu had already remarked earlier, in ns-3-reviews, that there is some > inconsistency with Ipv4L3Protocol trace sources: Drop and the new trace > sources include a separate IP header and the packet without the header, > while Tx and Rx include the packet with header already added. I did not > touch Tx and Rx because I do not need them, but if asked I am willing to > quickly align Tx and Rx with Drop, i.e. pass the header separated from the > packet payload. I have no idea what the consequences would be for users in terms of changing the API under their feet but I would support aligning Tx and Rx with Drop. Of course, tom is the only one who can decide on this but, well, just my 2 cents. Mathieu From mathieu.lacage at sophia.inria.fr Tue Sep 15 05:40:05 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 14:40:05 +0200 Subject: [Ns-developers] ns-3 blog Message-ID: <1253018405.23429.7.camel@diese.inria.fr> hi, Over a year ago (maybe two years ago), tom and I wanted to start an ns-3 blog to allow ns-3 developers to post entries about their current work and allow ns-3 users to follow the development of ns-3. Because we hoped that we would have time to produce content for this blog, we kept deferring announcing it but, well, it looks like none of us has any time to spare for this so, I thought that it probably would be a good idea to announce it as-is in the hope that some of the existing ns-3 contributors decide to post there: http://nsnam.blogspot.com/ If you are interested in posting there about your work with ns-3 or on ns-3, please, let me know: if you have a google/gmail account you can be given posting privileges. If at least one person starts posting there, I guess we can announce it on ns-3-users and post a url to it on our main page. Mathieu From mathieu.lacage at sophia.inria.fr Tue Sep 15 07:01:00 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 16:01:00 +0200 Subject: [Ns-developers] removing old tags Message-ID: <1253023260.24392.53.camel@diese.inria.fr> hi, Would anyone mind if I cleaned up the content of ns-3-dev/.hgtags to remove all *rc* entries to make the output of "hg tags" easier to look at ? Note: since the content of this file is actually tracked by mercurial, there is no risk of losing this information because it is still in the history. Mathieu From tomh at tomh.org Tue Sep 15 07:59:31 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 15 Sep 2009 08:59:31 -0600 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <1253017732.14583.70.camel@diese.inria.fr> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> Message-ID: <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> On Tue, 15 Sep 2009 14:28:52 +0200, Mathieu Lacage wrote: > On Tue, 2009-09-15 at 13:10 +0100, Gustavo Carneiro wrote: > >> Mathieu had already remarked earlier, in ns-3-reviews, that there is some >> inconsistency with Ipv4L3Protocol trace sources: Drop and the new trace >> sources include a separate IP header and the packet without the header, >> while Tx and Rx include the packet with header already added. I did not >> touch Tx and Rx because I do not need them, but if asked I am willing to >> quickly align Tx and Rx with Drop, i.e. pass the header separated from >> the >> packet payload. > > I have no idea what the consequences would be for users in terms of > changing the API under their feet but I would support aligning Tx and Rx > with Drop. Of course, tom is the only one who can decide on this but, > well, just my 2 cents. One thing that I noticed is that if we aim for such an alignment, there will be cases in which we need to manipulate a packet (push or strip an IPv4 header) just for providing to a trace source. This is because, at different locations in the IP layer, the packet may have a header or it or may not. Such a manipulation doesn't seem to be a good idea in general (to do work to massage input for a trace source to which nothing may be connected) because AddHeader triggers a deep copy. Should the priority instead be to avoid deep copies for the sake of tracing? Tom From gjcarneiro at gmail.com Tue Sep 15 08:15:32 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 15 Sep 2009 16:15:32 +0100 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> Message-ID: 2009/9/15 Tom Henderson > On Tue, 15 Sep 2009 14:28:52 +0200, Mathieu Lacage > wrote: > > On Tue, 2009-09-15 at 13:10 +0100, Gustavo Carneiro wrote: > > > >> Mathieu had already remarked earlier, in ns-3-reviews, that there is > some > >> inconsistency with Ipv4L3Protocol trace sources: Drop and the new trace > >> sources include a separate IP header and the packet without the header, > >> while Tx and Rx include the packet with header already added. I did not > >> touch Tx and Rx because I do not need them, but if asked I am willing to > >> quickly align Tx and Rx with Drop, i.e. pass the header separated from > >> the > >> packet payload. > > > > I have no idea what the consequences would be for users in terms of > > changing the API under their feet but I would support aligning Tx and Rx > > with Drop. Of course, tom is the only one who can decide on this but, > > well, just my 2 cents. > > One thing that I noticed is that if we aim for such an alignment, there > will be cases in which we need to manipulate a packet (push or strip an > IPv4 header) just for providing to a trace source. This is because, at > different locations in the IP layer, the packet may have a header or it or > may not. Such a manipulation doesn't seem to be a good idea in general (to > do work to massage input for a trace source to which nothing may be > connected) because AddHeader triggers a deep copy. > > Should the priority instead be to avoid deep copies for the sake of > tracing? > I am only arguing that at any given layer trace sources should be given the header, which already exists separately at that layer. If you look closely, you'll see that at IPv4 layer the Ipv4Header is already available somewhere within the send/deliver/forward methods. In the receive method, the Ipv4Header will be removed from the received packet sooner or later in that function--it makes no difference to remove it sooner rather than later. In the send method, the Ipv4Header is built inside the method and added to the packet before transmission--calling the Tx trace source before adding the header poses no performance penalty. Likewise, in forwarding function the header exists separately and is added inside the method. To summarize, I argue that it is often useful for trace callbacks to get access to the IP header, and that getting this IP header does not add any overhead. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Tue Sep 15 09:28:18 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 15 Sep 2009 18:28:18 +0200 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> Message-ID: <1253032098.2642.4.camel@localhost.localdomain> On Tue, 2009-09-15 at 08:59 -0600, Tom Henderson wrote: > >> Mathieu had already remarked earlier, in ns-3-reviews, that there is > some > >> inconsistency with Ipv4L3Protocol trace sources: Drop and the new trace > >> sources include a separate IP header and the packet without the header, > >> while Tx and Rx include the packet with header already added. I did not > >> touch Tx and Rx because I do not need them, but if asked I am willing to > >> quickly align Tx and Rx with Drop, i.e. pass the header separated from > >> the > >> packet payload. > > > > I have no idea what the consequences would be for users in terms of > > changing the API under their feet but I would support aligning Tx and Rx > > with Drop. Of course, tom is the only one who can decide on this but, > > well, just my 2 cents. > > One thing that I noticed is that if we aim for such an alignment, there > will be cases in which we need to manipulate a packet (push or strip an > IPv4 header) just for providing to a trace source. This is because, at > different locations in the IP layer, the packet may have a header or it or > may not. Such a manipulation doesn't seem to be a good idea in general (to > do work to massage input for a trace source to which nothing may be > connected) because AddHeader triggers a deep copy. I did not suggest that you add a header if it is not there. I merely suggested that we give an Ipv4Header extra argument to the trace callback. I thought that in all cases considered, the header was actually already available to the trace caller so, that the proposed changed was merely a matter of making it available to the callee. If I was wrong, then, I agree with you that it's not a good diea in general to attempt to add headers when they are not there because it has performance impacts. Either way, it's not a big issue: this was just my 2 euro cents. Mathieu From gjcarneiro at gmail.com Tue Sep 15 09:36:12 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 15 Sep 2009 17:36:12 +0100 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <1253032098.2642.4.camel@localhost.localdomain> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> <1253032098.2642.4.camel@localhost.localdomain> Message-ID: 2009/9/15 Mathieu Lacage > On Tue, 2009-09-15 at 08:59 -0600, Tom Henderson wrote: > > > >> Mathieu had already remarked earlier, in ns-3-reviews, that there is > > some > > >> inconsistency with Ipv4L3Protocol trace sources: Drop and the new > trace > > >> sources include a separate IP header and the packet without the > header, > > >> while Tx and Rx include the packet with header already added. I did > not > > >> touch Tx and Rx because I do not need them, but if asked I am willing > to > > >> quickly align Tx and Rx with Drop, i.e. pass the header separated from > > >> the > > >> packet payload. > > > > > > I have no idea what the consequences would be for users in terms of > > > changing the API under their feet but I would support aligning Tx and > Rx > > > with Drop. Of course, tom is the only one who can decide on this but, > > > well, just my 2 cents. > > > > One thing that I noticed is that if we aim for such an alignment, there > > will be cases in which we need to manipulate a packet (push or strip an > > IPv4 header) just for providing to a trace source. This is because, at > > different locations in the IP layer, the packet may have a header or it > or > > may not. Such a manipulation doesn't seem to be a good idea in general > (to > > do work to massage input for a trace source to which nothing may be > > connected) because AddHeader triggers a deep copy. > > I did not suggest that you add a header if it is not there. I merely > suggested that we give an Ipv4Header extra argument to the trace > callback. I thought that in all cases considered, the header was > actually already available to the trace caller so, that the proposed > changed was merely a matter of making it available to the callee. > > If I was wrong, then, I agree with you that it's not a good diea in > general to attempt to add headers when they are not there because it has > performance impacts. Either way, it's not a big issue: this was just my > 2 euro cents. > > If this is not a big deal I will ask to merge flow monitor as it is now, because time is running short. If people are so inclined, we can resolve this issue later (beyond NS 3.6 release if necessary). I even volunteer to make whatever changes are agreed upon. Tomorrow morning I merge the branch as it is now if I don't hear objections. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From gjcarneiro at gmail.com Tue Sep 15 09:49:22 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 15 Sep 2009 17:49:22 +0100 Subject: [Ns-developers] Ipv4RoutingHelper: Create vs Install? Message-ID: Why the rename from OlsrRoutingHelper from Install () to Create (). This seems rather inconsistent with the usual method names for the helpers, no?... Not having touched ns-3-dev in a while, I am a bit surprised by this, that is all. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From craigdo at ee.washington.edu Tue Sep 15 11:38:44 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 15 Sep 2009 11:38:44 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain><5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO><05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> Message-ID: <70B95BE965754CF0A0D316CF148C56E5@CRAIGVAIO> > I think I am ready to merge Flow Monitor. Okay. I will stay out of ns-3 dev tonight (your tomorrow morning) and let you push your bits. One thing: please either a) run the nightly build tests manually or b) watch for a buildbot error during your day. Regards, -- Craig From tom5760 at gmail.com Tue Sep 15 13:29:51 2009 From: tom5760 at gmail.com (Tom Wambold) Date: Tue, 15 Sep 2009 16:29:51 -0400 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> Message-ID: On Tue, Sep 15, 2009 at 3:43 AM, wrote: > The following new features have now been merged into ns-3-dev: > > 1. Testing and Validation Framework > 2. PacketBB (RFC 5444) I have made a small change to the PacketBB tests in order to use the new testing framework. It is in my repository at [1] under src/node/packetbb-test-suite.cc. Could you pull it into ns-3-dev? Thanks! -Tom Wambold [1] - http://code.nsnam.org/twambold/ns-3-dev-packetbb From tomh at tomh.org Tue Sep 15 14:25:38 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 15 Sep 2009 15:25:38 -0600 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> <1253032098.2642.4.camel@localhost.localdomain> Message-ID: <55680e2327787fef5ee763268d9fbd8f@tomh.org> Gustavo, Please clarify if I am mistaken, but here are the open issues with your trace sources and the IP traces in general: 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with your new traces and with the modified m_dropTrace? My opinion is that it would be OK to align these; this change should not cause a soft (undetected) error in users scripts, and you are already modifying m_dropTrace. 2) does the Packet passed to the trace sources have an IP header or not, and is it important to have consistency across these traces? In your proposal, m_dropTrace and your new traces pass a Packet pointer without IP header. I see that you have made sure that m_dropTrace is consistent in that regard. However, m_txTrace/m_rxTrace Packet presently includes the IP header. m_txTrace and m_rxTrace live right at the boundary of the IPv4 model, so conceptually they are hit just before giving to the outgoing device or just after receiving (before any logic is applied to the packet contents). I do not feel strongly either way about whether m_txTrace or m_rxTrace pass a packet with or without the IP header, so long as it is documented which way it is, and so long as it is consistent within the trace source itself. Are there other opinions on this? 3) Future netfilter alignment, and placement of traces in general. You suggested in the ns-3-reviews thread that you thought it would be good to place these traces after any corresponding netfilter hook has returned. It seems like the new ones roughly map as follows: m_sendOutgoingTrace -> POSTROUTING m_unicastForward -> FORWARD (although only unicast forwarding) m_localDeliver -> LOCAL_IN When netfilter is added, the trace sources may have to be moved in the code slightly, which may slightly change the packets that they see. I don't think this is a big deal right now. One design issue that probably needs to be considered now is how Netfilter API is expected to be added. We are presently stripping the packet header early in the IPv4 Receive process and adding it back just before sending it out. So, packets passed to Netfilter will not have IP headers. With the current APIs, Netfilter will have to separately handle a Ptr and Ipv4Header and be able to pass back a modified IP header that will need to go forward with the packet, and if the Netfilter client code expects to mangle everything within a packed packet structure, that would mean doing AddHeader(), mangle, RemoveHeader() which seems not so great. I'll look at Qasim's repo later and think about the consequences of this. Tom From gjcarneiro at gmail.com Tue Sep 15 15:28:33 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 15 Sep 2009 23:28:33 +0100 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) Message-ID: 2009/9/15 Tom Henderson > Gustavo, > Please clarify if I am mistaken, but here are the open issues with your > trace sources and the IP traces in general: > > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with your > new traces and with the modified m_dropTrace? > > My opinion is that it would be OK to align these; this change should not > cause a soft (undetected) error in users scripts, and you are already > modifying m_dropTrace. > Yes, I regret to modify m_dropTrace. On one hand I hat breaking API/ABI/behavior (either "soft" or "hard"), you know I really do. On the other hand if I had added a new MyAlternativeDrop trace I just know I would receive comments from you, Mathieu, or Craig saying that I was duplicating functionality, etc. Now txTrace and rxTrace modifications will break even more APIs. Programs will not even fail at runtime, just Config::Connect will have no effect due to non-matching Callback signature. No, I do _not_ like this, but if you want consistency I don't see any other option. > > 2) does the Packet passed to the trace sources have an IP header or not, > and is it important to have consistency across these traces? > > In your proposal, m_dropTrace and your new traces pass a Packet pointer > without IP header. I see that you have made sure that m_dropTrace is > consistent in that regard. However, m_txTrace/m_rxTrace Packet presently > includes the IP header. m_txTrace and m_rxTrace live right at the > boundary of the IPv4 model, so conceptually they are hit just before giving > to the outgoing device or just after receiving (before any logic is applied > to the packet contents). I do not feel strongly either way about whether > m_txTrace or m_rxTrace pass a packet with or without the IP header, so long > as it is documented which way it is, and so long as it is consistent within > the trace source itself. Are there other opinions on this? > I am also willing (not my preferred choice, but...) to go back the other way: make all trace sources, including the Drop and new ones, pass a packet with an IP header already serialized. Maybe performance won't be so great, but if it unblocks the merge then it may be worth the effort. I expect that at least PeekHeader should not be slow... > > 3) Future netfilter alignment, and placement of traces in general. > > You suggested in the ns-3-reviews thread that you thought it would be good > to place these traces after any corresponding netfilter hook has returned. > It seems like the new ones roughly map as follows: > m_sendOutgoingTrace -> POSTROUTING > m_unicastForward -> FORWARD (although only unicast forwarding) > m_localDeliver -> LOCAL_IN > > When netfilter is added, the trace sources may have to be moved in the code > slightly, which may slightly change the packets that they see. I don't > think this is a big deal right now. > > One design issue that probably needs to be considered now is how Netfilter > API is expected to be added. We are presently stripping the packet header > early in the IPv4 Receive process and adding it back just before sending it > out. So, packets passed to Netfilter will not have IP headers. With the > current APIs, Netfilter will have to separately handle a Ptr and > Ipv4Header and be able to pass back a modified IP header that will need to > go forward with the packet, and if the Netfilter client code expects to > mangle everything within a packed packet structure, that would mean doing > AddHeader(), mangle, RemoveHeader() which seems not so great. Correct. Maybe it is better for the Netfilter code to receive and return back also the IP header. It's probably more efficient too. This is basically what the Ipv4routingProtocol (at least the way I had implemented it initially, no idea if it has changed) did too: it received a packet without IP header plus the IP header, and it returned back a possibly modified packet plus possibly modified IP header. Thanks, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From tomh at tomh.org Tue Sep 15 16:40:35 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 15 Sep 2009 17:40:35 -0600 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: References: Message-ID: On Tue, 15 Sep 2009 23:28:33 +0100, Gustavo Carneiro wrote: > 2009/9/15 Tom Henderson > >> Gustavo, >> Please clarify if I am mistaken, but here are the open issues with your >> trace sources and the IP traces in general: >> >> 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with >> your >> new traces and with the modified m_dropTrace? >> >> My opinion is that it would be OK to align these; this change should not >> cause a soft (undetected) error in users scripts, and you are already >> modifying m_dropTrace. >> > > Yes, I regret to modify m_dropTrace. On one hand I hat breaking > API/ABI/behavior (either "soft" or "hard"), you know I really do. On the > other hand if I had added a new MyAlternativeDrop trace I just know I would > receive comments from you, Mathieu, or Craig saying that I was duplicating > functionality, etc. Now txTrace and rxTrace modifications will break even > more APIs. Programs will not even fail at runtime, just Config::Connect > will have no effect due to non-matching Callback signature. I believe that they will fail at runtime due to signature mismatch. I just verified this in one of the example programs. > No, I do _not_ > like this, but if you want consistency I don't see any other option. > > >> >> 2) does the Packet passed to the trace sources have an IP header or not, >> and is it important to have consistency across these traces? >> >> In your proposal, m_dropTrace and your new traces pass a Packet pointer >> without IP header. I see that you have made sure that m_dropTrace is >> consistent in that regard. However, m_txTrace/m_rxTrace Packet presently >> includes the IP header. m_txTrace and m_rxTrace live right at the >> boundary of the IPv4 model, so conceptually they are hit just before >> giving >> to the outgoing device or just after receiving (before any logic is >> applied >> to the packet contents). I do not feel strongly either way about whether >> m_txTrace or m_rxTrace pass a packet with or without the IP header, so >> long >> as it is documented which way it is, and so long as it is consistent >> within >> the trace source itself. Are there other opinions on this? >> > > I am also willing (not my preferred choice, but...) to go back the other > way: make all trace sources, including the Drop and new ones, pass a packet > with an IP header already serialized. Maybe performance won't be so great, > but if it unblocks the merge then it may be worth the effort. I expect > that > at least PeekHeader should not be slow... If consistency here is the goal, I think that providing packets w/o the IP header will be better. > > >> >> 3) Future netfilter alignment, and placement of traces in general. >> >> You suggested in the ns-3-reviews thread that you thought it would be >> good >> to place these traces after any corresponding netfilter hook has >> returned. >> It seems like the new ones roughly map as follows: >> m_sendOutgoingTrace -> POSTROUTING >> m_unicastForward -> FORWARD (although only unicast forwarding) >> m_localDeliver -> LOCAL_IN >> >> When netfilter is added, the trace sources may have to be moved in the >> code >> slightly, which may slightly change the packets that they see. I don't >> think this is a big deal right now. >> >> One design issue that probably needs to be considered now is how >> Netfilter >> API is expected to be added. We are presently stripping the packet >> header >> early in the IPv4 Receive process and adding it back just before sending >> it >> out. So, packets passed to Netfilter will not have IP headers. With the >> current APIs, Netfilter will have to separately handle a Ptr and >> Ipv4Header and be able to pass back a modified IP header that will need >> to >> go forward with the packet, and if the Netfilter client code expects to >> mangle everything within a packed packet structure, that would mean doing >> AddHeader(), mangle, RemoveHeader() which seems not so great. > > > Correct. Maybe it is better for the Netfilter code to receive and return > back also the IP header. It's probably more efficient too. This is > basically what the Ipv4routingProtocol (at least the way I had implemented > it initially, no idea if it has changed) did too: it received a packet > without IP header plus the IP header, and it returned back a possibly > modified packet plus possibly modified IP header. > Yes, the IPv4 headers are still passed separately. Tom From tunc at ku.edu Tue Sep 15 09:00:19 2009 From: tunc at ku.edu (Tunc, Muharrem Ali) Date: Tue, 15 Sep 2009 11:00:19 -0500 Subject: [Ns-developers] Efforts to implement TDMA MAC Layer and FEC techniques in the Physical Layer Message-ID: <56F7AE7F5790674CA5C800189A9A83870D9FC3@MAILBOX-33.home.ku.edu> Hello, We would like to develop TDMA MAC Layer and FEC in the physical layer. We are wondering if there is already someone working on implementing TDMA MAC Layer or FEC techniques in the physical layer and if those two will be available sometime soon in the new releases of NS-3. Thanks, M. Ali Tunc From egemen.cetinkaya at gmail.com Tue Sep 15 13:48:19 2009 From: egemen.cetinkaya at gmail.com (Egemen Cetinkaya) Date: Tue, 15 Sep 2009 15:48:19 -0500 Subject: [Ns-developers] Development of new routing protocol In-Reply-To: References: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> Message-ID: <5c2d9c8b0909151348q5f7b2557ufb7756689074b13b@mail.gmail.com> Dear all, First of all I would like to thank you for the responses. I think that we will shoot for the implementation of DSDV. As the other ideas sound good, this will be a course term project, and we are time and headcount constrained. Originally, we were also thinking to look to ns-2 source code to get some idea about DSDV implementation (maybe port it from ns-2 to ns-3?). Is there any other suggestions while implementing DSDV in ns-3? We will most definitely need to look at the AODV code. Is there any specific test cases you would like to be tested while we look at AODV implementation? What's the timeline you are looking? We can't look at it immediately, but in the next few weeks. Finally, what's the planned ns-3 release for AODV? Best regards, Egemen Cetinkaya 2009/9/12 Pavel Boyko > Hi, Egemen, > > On Thu, 10 Sep 2009 20:39:42 -0500 > Egemen Cetinkaya wrote: > >> We are wondering if anyone is developing AODV, DSR, DSDV for ns-3? >> >> I saw couple of threads once I Googled AODV and ns-3, but wanted to make >> sure that if we are intending to develop new protocol, we are not going to >> duplicate the efforts. >> > > We have finished AODV implementation recently, please find more info here: > http://mailman.isi.edu/pipermail/ns-developers/2009-September/006497.html > > >> Also if AODV is in the pipe, what's the next routing protocol that user's >> would like to see most? >> > > Personally I'd like to: > 0) encourage you to review and test our AODV implementation > 1) see OLSR working, it is implemented but seems to be broken by IP > routing rework of ns-3.5. > 2) see multicast AODV (MAODV) implemented > 3) also SMF would be great, though it is not routing > 4) DYMO, but I guess this idea is already popular > 5) NHDP & OLSRv2, but ask PacketBB authors first > > Good luck, > Pavel > From gspathara at gmail.com Mon Sep 14 13:30:55 2009 From: gspathara at gmail.com (FSP) Date: Mon, 14 Sep 2009 13:30:55 -0700 (PDT) Subject: [Ns-developers] Chen's wimax module source code request Message-ID: <25443035.post@talk.nabble.com> Hi all, I would appreciate if anyone can give me the source code of Chen's wimax module because the link of his personal page is down. Thanks in advance! -- View this message in context: http://www.nabble.com/Chen%27s-wimax-module-source-code-request-tp25443035p25443035.html Sent from the ns-developers mailing list archive at Nabble.com. From gspathara at gmail.com Mon Sep 14 09:16:14 2009 From: gspathara at gmail.com (FSP) Date: Mon, 14 Sep 2009 09:16:14 -0700 (PDT) Subject: [Ns-developers] Jenhui Chen's wimax module In-Reply-To: <25415578.post@talk.nabble.com> References: <25415578.post@talk.nabble.com> Message-ID: <25438800.post@talk.nabble.com> I'm talking about the module in the following page.... http://ndsl.csie.cgu.edu.tw/wimax_ns2.php which is down for some time.... -- View this message in context: http://www.nabble.com/Jenhui-Chen%27s-wimax-module-tp25415578p25438800.html Sent from the ns-developers mailing list archive at Nabble.com. From boyko at iitp.ru Wed Sep 16 00:53:44 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Wed, 16 Sep 2009 11:53:44 +0400 Subject: [Ns-developers] Development of new routing protocol In-Reply-To: <5c2d9c8b0909151348q5f7b2557ufb7756689074b13b@mail.gmail.com> References: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> <5c2d9c8b0909151348q5f7b2557ufb7756689074b13b@mail.gmail.com> Message-ID: <200909161153.45008.boyko@iitp.ru> Hi, Egemen, > I think that we will shoot for the implementation of DSDV. As the other > ideas sound good, this will be a course term project, and we are time and > headcount constrained. Our experience show that AODV model can be implemented from scratch by approx. 2.5 student-months. If you have comparable resources I'd suggest you to consider something more interesting and useful than DSDV. Frankly speaking I don't believe that dsdv model will find users. > Originally, we were also thinking to look to ns-2 source code to get some > idea about DSDV implementation (maybe port it from ns-2 to ns-3?). Is there > any other suggestions while implementing DSDV in ns-3? Our attempt to port ns-2 aodv model has failed because of its awful quality, though this doesn't mean that dsdv model is ugly too. Also you should note that packet flow and routing framework in ns-2 are quite different from ns-3 ones. > We will most definitely need to look at the AODV code. Is there any > specific test cases you would like to be tested while we look at AODV > implementation? What's the timeline you are looking? We can't look at it > immediately, but in the next few weeks. Finally, what's the planned ns-3 > release for AODV? We just interested in growing aodv model user base, nothing else. I don't have specific test cases and time frames for you. Also I don't have specific plans to merge aodv model into the ns-3 mainline -- that depends on users feedback. Regards, Pavel > 2009/9/12 Pavel Boyko > > > Hi, Egemen, > > > > On Thu, 10 Sep 2009 20:39:42 -0500 > > > > Egemen Cetinkaya wrote: > >> We are wondering if anyone is developing AODV, DSR, DSDV for ns-3? > >> > >> I saw couple of threads once I Googled AODV and ns-3, but wanted to make > >> sure that if we are intending to develop new protocol, we are not going > >> to duplicate the efforts. > > > > We have finished AODV implementation recently, please find more info > > here: > > http://mailman.isi.edu/pipermail/ns-developers/2009-September/006497.html > > > >> Also if AODV is in the pipe, what's the next routing protocol that > >> user's would like to see most? > > > > Personally I'd like to: > > 0) encourage you to review and test our AODV implementation > > 1) see OLSR working, it is implemented but seems to be broken by IP > > routing rework of ns-3.5. > > 2) see multicast AODV (MAODV) implemented > > 3) also SMF would be great, though it is not routing > > 4) DYMO, but I guess this idea is already popular > > 5) NHDP & OLSRv2, but ask PacketBB authors first > > > > Good luck, > > Pavel From riley at ece.gatech.edu Wed Sep 16 08:13:37 2009 From: riley at ece.gatech.edu (George Riley) Date: Wed, 16 Sep 2009 11:13:37 -0400 Subject: [Ns-developers] ns3 stock topology objects Message-ID: <5453BD21-E5BE-48EA-B2D5-87D79C049600@ece.gatech.edu> Hi All, After lengthly discussion with Tom, I am proposing a philosophical shift in the design of "stock topology" objects. The only current such object is the "Star" topology, defined in point-to-point-helper.h: void InstallStar (Ptr hub, NodeContainer spokes, NetDeviceContainer& hubDevices, NetDeviceContainer& spokeDevices); In this design, the caller of the InstallStar must pass in various containers that are populated by the function and returned to the caller. If the caller can make assumptions about the order in which the various nodes and links are assigned, he can then find the various links, queues, etc in the star topology. For the simple Star, this works fine. However for more complex topologies, this no longer holds together. Consider the Dumbbell topology for example. Just getting back a container of the devices (as above) is not sufficient, as I would need to know in which order are the devices created (bottle neck routers first, left side leafs, right side leafs, etc) in order to find the various components. What is up for review is a different approach. The point-to-point- dumbbell.h/cc contains the complete implementation for constructing a dumbbell, and hides the detail from the user. The user just says how many leaf nodes on each side and provides a point-to-point-helper to be used to connect leaf nodes to the bottleneck, and the bottleneck routers together (which could be the same or different helpers depending you the requirements). Also provided are member functions for querying the various components of the dumbbell (left leaf[i], left router, etc) The internals of how the dumbbell is hidden from the user, since he does not need any such information. Finally, the assignment of IP addresses is a separate action from the creation of the topology per Tom's request. We also are providing a Point-to-Point-Grid object with similar design and capabilities. Assuming this is ok, we suggest also creating a new "point-to-point- star" object to replace the current InstallStar capability, but leaving existing capability for one release cycle. We can add a warning in InstallStar saying something like "Deprecated, use point-to-point-star instead", or something like that. The dumbell class declaration is: (actually after cut-pasting this I realize it should say "PointToPointDumbell" for the class name. Will fix) class Dumbbell { public: Dumbbell(uint32_t nLeftLeaf, // Number of left size leaf nodes PointToPointHelper& leftHelper, uint32_t nRightLeaf, // Number of right side leaf nodes PointToPointHelper& rightHelper, PointToPointHelper& bottleneckHelper); public: Ptr GetLeft() const; // Get the left side bottleneck router Ptr GetLeft(uint32_t) const; // Get the i'th left side leaf Ptr GetRight() const; // Get the right side bottleneck router Ptr GetRight(uint32_t) const; // Get the i'th right side leaf Ipv4Address GetLeftAddress(uint32_t) const; // Get left leaf address Ipv4Address GetRightAddress(uint32_t) const; // Get right leaf address uint32_t LeftCount() const; // Number of left side nodes uint32_t RightCount() const; // Number of right side nodes void AssignAddresses(Ipv4AddressHelper leftIp, Ipv4AddressHelper rightIp, Ipv4AddressHelper routerIp); // Add locations in the specified bounding box // Arguments are uppler left x, upper left y, lower right x, lower right y void BoundingBox(double, double, double, double); private: NodeContainer m_leftLeaf; NetDeviceContainer m_leftLeafDevices; NodeContainer m_rightLeaf; NetDeviceContainer m_rightLeafDevices; NodeContainer m_routers; NetDeviceContainer m_routerDevices; // just two connecting the routers // Device containers for the router devices connecting to the leaf devices NetDeviceContainer m_leftRouterDevices; NetDeviceContainer m_rightRouterDevices; Ipv4InterfaceContainer m_leftLeafInterfaces; Ipv4InterfaceContainer m_leftRouterInterfaces; Ipv4InterfaceContainer m_rightLeafInterfaces; Ipv4InterfaceContainer m_rightRouterInterfaces; Ipv4InterfaceContainer m_routerInterfaces; }; -------------------------------------------------- George Riley Associate Professor Georgia Tech Electrical and Computer Engineering riley at ece.gatech.edu 404-894-4767 Klaus Advanced Computing Building Room 3360 266 Ferst Drive Atlanta, Georgia 30332-0765 ECE6110 Web page: http://users.ece.gatech.edu/~riley/ece6110/ ECE3090 Web page: http://users.ece.gatech.edu/~riley/ece3090/ From gjcarneiro at gmail.com Wed Sep 16 09:26:17 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 16 Sep 2009 17:26:17 +0100 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> Message-ID: 2009/9/15 Gustavo Carneiro > > > 2009/9/15 Tom Henderson > > On Tue, 15 Sep 2009 14:28:52 +0200, Mathieu Lacage >> wrote: >> > On Tue, 2009-09-15 at 13:10 +0100, Gustavo Carneiro wrote: >> > >> >> Mathieu had already remarked earlier, in ns-3-reviews, that there is >> some >> >> inconsistency with Ipv4L3Protocol trace sources: Drop and the new trace >> >> sources include a separate IP header and the packet without the header, >> >> while Tx and Rx include the packet with header already added. I did >> not >> >> touch Tx and Rx because I do not need them, but if asked I am willing >> to >> >> quickly align Tx and Rx with Drop, i.e. pass the header separated from >> >> the >> >> packet payload. >> > >> > I have no idea what the consequences would be for users in terms of >> > changing the API under their feet but I would support aligning Tx and Rx >> > with Drop. Of course, tom is the only one who can decide on this but, >> > well, just my 2 cents. >> >> One thing that I noticed is that if we aim for such an alignment, there >> will be cases in which we need to manipulate a packet (push or strip an >> IPv4 header) just for providing to a trace source. This is because, at >> different locations in the IP layer, the packet may have a header or it or >> may not. Such a manipulation doesn't seem to be a good idea in general >> (to >> do work to massage input for a trace source to which nothing may be >> connected) because AddHeader triggers a deep copy. >> >> Should the priority instead be to avoid deep copies for the sake of >> tracing? >> > > I am only arguing that at any given layer trace sources should be given the > header, which already exists separately at that layer. If you look closely, > you'll see that at IPv4 layer the Ipv4Header is already available somewhere > within the send/deliver/forward methods. In the receive method, the > Ipv4Header will be removed from the received packet sooner or later in that > function--it makes no difference to remove it sooner rather than later. In > the send method, the Ipv4Header is built inside the method and added to the > packet before transmission--calling the Tx trace source before adding the > header poses no performance penalty. Likewise, in forwarding function the > header exists separately and is added inside the method. > > To summarize, I argue that it is often useful for trace callbacks to get > access to the IP header, and that getting this IP header does not add any > overhead. > > Attached patch to make Rx/Tx pass the IP header separately, and the Packet contain only the IP payload. A disadvantage I discovered with this is that InternetStackHelper::EnablePcapAll needs the packet _with_ IP header, so I had to add code to Copy() and AddHeader before writing to pcap. So... not really a clear cut decision: one approach makes Flow Monitor slower, the other makes IP layer pcap writing slower. Maybe a good compromise solution is to pass the Ipv[46]Header separately _and_ pass the Packet with IP header serialized as before. Although time is running short for the merge. I am doing the Flow Monitor merge without this patch and open a bug report for solving the issue. Merge done... Bug report done: http://www.nsnam.org/bugzilla/show_bug.cgi?id=676 -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- A non-text attachment was scrubbed... Name: p.diff Type: text/x-patch Size: 12381 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090916/f71edf13/p-0001.bin From craigdo at ee.washington.edu Wed Sep 16 10:29:36 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 16 Sep 2009 10:29:36 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain><5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> Message-ID: <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> Hi All, The cutoff date for adding new features to ns-3.6 is today. Time flies when you are having fun, eh? My current list of unresolved candidates for merge is: Feature Description Responsible People? --------------------------------------------- ------------------------- 1. Nix-Vector Routing ....................... George Riley, Josh Pelkey 2. WiMAX Models ............................. Faker Moatamri et al. 3. 802.11 10 MHz Channel .................... Ramon Bauza 4. NetAnim Animator Support ................. George Riley, Josh Pelkey 5. Miscellaneous ............................ Timo Bingmann 6. Patch to Pause and Resume an Interface ... Adrian Tam We can get one, possibly two, of these features into ns-3 if we start merging soon. Since I have only seen activity on two of these candidates, I am going to assume that everyone else is dropping out and we are left with: 1. Nix-Vector Routing ....................... George Riley, Josh Pelkey 2. NetAnim Animator Support ................. George Riley, Josh Pelkey As I understand it, the issues remaining are: --- 1. Nix-Vector Routing A Nix-Vector-specific object pointer was added to Packet to support this routing package but I believe this has been moved to PacketMetadata. I still personally don't like this very much since it is a solution to a specific problem encoded in a generic class (and actually PacketMetadata is designed for something slightly different). I could live with it temporarily if it is felt that Nix vectors are a huge win in complicated (George's Campus) simulations. I could live with it slightly more comfortably if the Ptr was a Ptr so we could at least pretend this was a generic thing :-) I think there needs to be a wider discussion on supporting what seems to essentially be object aggregation to packet metadata, but I don't think we need to hold up this feature for that debate. 2. NetAnim Animator Support There seems to be a philosophy-of-helper issue brewing regarding this. My opinion is that it is way too late in the release process for this kind of discussion to be taking place. It has been proposed that this feature could go into src/contrib until the helper questions are answered. I think this is okay. --- It sounds to me like we could get this stuff merged in fairly short order if we get a few +1 comments and if the features just slide in and work. Comments? -- Craig From craigdo at ee.washington.edu Wed Sep 16 13:35:31 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 16 Sep 2009 13:35:31 -0700 Subject: [Ns-developers] Last Comments on Merge Queue for Ns-3.6 Release In-Reply-To: <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain><5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO><05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> Message-ID: Hi All, There has been some last-minute scrambling to figure out how to proceed with the last two merge items: 1. Nix-Vector Routing ....................... George Riley, Josh Pelkey 2. NetAnim Animator Support ................. George Riley, Josh Pelkey For nix-vector routing the proposal is: Go ahead and use a specific pointer of type Ptr for now in Packet. Comment clearly that this is a temporary solution to a specific problem in a generic class and should not be taken as guidance on how to solve this kind of problem in the future -- this API essentially goes in as deprecated. We file a P2 bug on this (must be fixed by next release) and discuss and implement a more generic way to associate objects with packets for that next release, whereupon the specific NixVector Ptr is removed in favor of the new mechanism. Nix-Vector Routing can then be merged immediately. For NetAnim Animator Support the proposal is: Go ahead and push the code with the trace source in the net-devices. File a P1 bug to add an "appropriately generic trace source useful to the animator" to the generic channel class, add "/ChannelList" to the config namespace so that the new trace source can be hooked in a reasonable way, and move the animator over to use the new trace source via "/ChannelList/n/TraceName". The P1-ness of the bug implies that it must be fixed before release -- so we aren't giving (a new trace source) in one release and then taking it away in the next. The trick to this is going to be "an appropriately generic trace source useful to the animator." NetAnim Animator Support can then be merged immediately if the P1 bug is filed. I am cutting a little slack and allowing a full day for comments from around the globe before taking a final decision on this. If this approach seems agreeable I will push these last two features starting tomorrow afternoon. Tom, George and I are okay with it. Reply now or forever hold your peace :-) Regards, -- Craig From mathieu.lacage at sophia.inria.fr Wed Sep 16 17:10:26 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 16 Sep 2009 17:10:26 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200909170010.n8H0AQeh006629@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/160 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Sep 16 17:30:35 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 16 Sep 2009 17:30:35 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200909170030.n8H0UZcY006653@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/154 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Sep 16 17:54:36 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 16 Sep 2009 17:54:36 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200909170054.n8H0sasm006674@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/147 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Sep 16 18:10:52 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 16 Sep 2009 18:10:52 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.3.2 Message-ID: <200909170110.n8H1AqWw006693@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.3.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.3.2/builds/142 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Sep 16 18:26:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 16 Sep 2009 18:26:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200909170126.n8H1QnRC006715@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/159 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 sincerely, -The Buildbot From dnlove at gmail.com Wed Sep 16 20:20:35 2009 From: dnlove at gmail.com (Duy Nguyen) Date: Wed, 16 Sep 2009 20:20:35 -0700 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: References: Message-ID: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> Hi Gustavo, I just tested out your flow monitor and find it very useful. However, I am not able to use it for multiple flows. I attach my test case in this email. Maybe I make a mistake somewhere in my scripts, but I could not figure it out, could you help me take a look? I attached many-flows.cc in this email. I set up 3x3 grid with 9 nodes total, but you many increase it to however many nodes or flows you like. Environment is a multi-hop adhoc with either olsr/aodv Flow 1: node 0-> node 1 Flow 2: node 2-> node 3 Flow 3: node 4-> node 5 Flow 4: node 6-> node 7 and this is many-flows.flowmo > 2009/9/15 Tom Henderson > > > Gustavo, > > Please clarify if I am mistaken, but here are the open issues with your > > trace sources and the IP traces in general: > > > > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with > your > > new traces and with the modified m_dropTrace? > > > > My opinion is that it would be OK to align these; this change should not > > cause a soft (undetected) error in users scripts, and you are already > > modifying m_dropTrace. > > > > Yes, I regret to modify m_dropTrace. On one hand I hat breaking > API/ABI/behavior (either "soft" or "hard"), you know I really do. On the > other hand if I had added a new MyAlternativeDrop trace I just know I would > receive comments from you, Mathieu, or Craig saying that I was duplicating > functionality, etc. Now txTrace and rxTrace modifications will break even > more APIs. Programs will not even fail at runtime, just Config::Connect > will have no effect due to non-matching Callback signature. No, I do _not_ > like this, but if you want consistency I don't see any other option. > > > > > > 2) does the Packet passed to the trace sources have an IP header or not, > > and is it important to have consistency across these traces? > > > > In your proposal, m_dropTrace and your new traces pass a Packet pointer > > without IP header. I see that you have made sure that m_dropTrace is > > consistent in that regard. However, m_txTrace/m_rxTrace Packet presently > > includes the IP header. m_txTrace and m_rxTrace live right at the > > boundary of the IPv4 model, so conceptually they are hit just before > giving > > to the outgoing device or just after receiving (before any logic is > applied > > to the packet contents). I do not feel strongly either way about whether > > m_txTrace or m_rxTrace pass a packet with or without the IP header, so > long > > as it is documented which way it is, and so long as it is consistent > within > > the trace source itself. Are there other opinions on this? > > > > I am also willing (not my preferred choice, but...) to go back the other > way: make all trace sources, including the Drop and new ones, pass a packet > with an IP header already serialized. Maybe performance won't be so great, > but if it unblocks the merge then it may be worth the effort. I expect > that > at least PeekHeader should not be slow... > > > > > > 3) Future netfilter alignment, and placement of traces in general. > > > > You suggested in the ns-3-reviews thread that you thought it would be > good > > to place these traces after any corresponding netfilter hook has > returned. > > It seems like the new ones roughly map as follows: > > m_sendOutgoingTrace -> POSTROUTING > > m_unicastForward -> FORWARD (although only unicast forwarding) > > m_localDeliver -> LOCAL_IN > > > > When netfilter is added, the trace sources may have to be moved in the > code > > slightly, which may slightly change the packets that they see. I don't > > think this is a big deal right now. > > > > One design issue that probably needs to be considered now is how > Netfilter > > API is expected to be added. We are presently stripping the packet > header > > early in the IPv4 Receive process and adding it back just before sending > it > > out. So, packets passed to Netfilter will not have IP headers. With the > > current APIs, Netfilter will have to separately handle a Ptr and > > Ipv4Header and be able to pass back a modified IP header that will need > to > > go forward with the packet, and if the Netfilter client code expects to > > mangle everything within a packed packet structure, that would mean doing > > AddHeader(), mangle, RemoveHeader() which seems not so great. > > > Correct. Maybe it is better for the Netfilter code to receive and return > back also the IP header. It's probably more efficient too. This is > basically what the Ipv4routingProtocol (at least the way I had implemented > it initially, no idea if it has changed) did too: it received a packet > without IP header plus the IP header, and it returned back a possibly > modified packet plus possibly modified IP header. > > Thanks, > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > -------------- next part -------------- A non-text attachment was scrubbed... Name: many-flows.cc Type: text/x-c++src Size: 8485 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090916/3716bf4e/many-flows-0001.bin From tomh at tomh.org Wed Sep 16 21:52:42 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 16 Sep 2009 21:52:42 -0700 Subject: [Ns-developers] Last Comments on Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain><5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO><05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> Message-ID: <4AB1C09A.601@tomh.org> craigdo at ee.washington.edu wrote: > Hi All, > > There has been some last-minute scrambling to figure out how to proceed with > the last two merge items: > > 1. Nix-Vector Routing ....................... George Riley, Josh Pelkey > 2. NetAnim Animator Support ................. George Riley, Josh Pelkey > > For nix-vector routing the proposal is: > > Go ahead and use a specific pointer of type Ptr for now in > Packet. Comment clearly that this is a temporary solution to a specific > problem in a generic class and should not be taken as guidance on how to > solve this kind of problem in the future -- this API essentially goes in as > deprecated. > > We file a P2 bug on this (must be fixed by next release) and discuss and > implement a more generic way to associate objects with packets for that next > release, whereupon the specific NixVector Ptr is removed in favor of the new > mechanism. > > Nix-Vector Routing can then be merged immediately. > > For NetAnim Animator Support the proposal is: > > Go ahead and push the code with the trace source in the net-devices. File a > P1 bug to add an "appropriately generic trace source useful to the animator" > to the generic channel class, add "/ChannelList" to the config namespace so > that the new trace source can be hooked in a reasonable way, and move the > animator over to use the new trace source via "/ChannelList/n/TraceName". > The P1-ness of the bug implies that it must be fixed before release -- so we > aren't giving (a new trace source) in one release and then taking it away in > the next. > > The trick to this is going to be "an appropriately generic trace source > useful to the animator." > > NetAnim Animator Support can then be merged immediately if the P1 bug is > filed. I would prefer to see the new helpers go into src/contrib/netanim for this release cycle. I agree with George that it would be helpful to have these new topology objects in the simulator and I think we'll end up with something close to what is posted now, but I think there are still some open issues (which I'll post on the codereview issue). Tom From mathieu.lacage at sophia.inria.fr Wed Sep 16 23:41:57 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 08:41:57 +0200 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> Message-ID: <1253169717.24392.76.camel@diese.inria.fr> On Wed, 2009-09-16 at 10:29 -0700, craigdo at ee.washington.edu wrote: > 1. Nix-Vector Routing > > A Nix-Vector-specific object pointer was added to Packet to support this > routing package but I believe this has been moved to PacketMetadata. I > still personally don't like this very much since it is a solution to a > specific problem encoded in a generic class (and actually PacketMetadata is > designed for something slightly different). > > I could live with it temporarily if it is felt that Nix vectors are a huge > win in complicated (George's Campus) simulations. I could live with it > slightly more comfortably if the Ptr was a Ptr so we > could at least pretend this was a generic thing :-) > > I think there needs to be a wider discussion on supporting what seems to > essentially be object aggregation to packet metadata, but I don't think we > need to hold up this feature for that debate. I do agree with you that it's a really bad idea to add this adhoc nix vector pointer to the generic packet class. The real solution is to add the needed support to 'packet tags' but I don't have time to do this myself and no one appears to be interested in trying to do the research needed to figure out if it is actually possible and if so, do it. To summarize, I don't like this but there is pressure to merge this and I can't convince myself that the bad karma I would get for giving a -1 as-is is worth the gain of keeping the packet class 'clean'. i.e., if we find out that this is a really bad idea, we can easily remove this code later. > 2. NetAnim Animator Support > > There seems to be a philosophy-of-helper issue brewing regarding this. My > opinion is that it is way too late in the release process for this kind of > discussion to be taking place. It has been proposed that this feature could > go into src/contrib until the helper questions are answered. I think this > is okay. I did not follow the discussions but if there is really a philosophical discussion going on, it does not sound like a good idea to merge it, even in src/contrib, especially so late in the release cycle. What is sad is that this code has been waiting for review for quite a long time so, we (those who review code) are mostly responsible for this lateness in the discussion. I don't have any good input here: both options appear to not be optimal. Mathieu From mathieu.lacage at sophia.inria.fr Wed Sep 16 23:44:38 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 08:44:38 +0200 Subject: [Ns-developers] Last Comments on Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> Message-ID: <1253169878.24392.78.camel@diese.inria.fr> On Wed, 2009-09-16 at 13:35 -0700, craigdo at ee.washington.edu wrote: > The trick to this is going to be "an appropriately generic trace source > useful to the animator." [wifi maintainer on] Could you point me to the relevant proposed change so that I can make sure that it's not a killer for wifi ? (sorry for not answering yesterday: I was traveling without internet connection) Mathieu From mathieu.lacage at sophia.inria.fr Wed Sep 16 23:46:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 08:46:23 +0200 Subject: [Ns-developers] Ipv4RoutingHelper: Create vs Install? In-Reply-To: References: Message-ID: <1253169983.24392.80.camel@diese.inria.fr> On Tue, 2009-09-15 at 17:49 +0100, Gustavo Carneiro wrote: > Why the rename from OlsrRoutingHelper from Install () to Create (). This > seems rather inconsistent with the usual method names for the helpers, > no?... The way it's expected to be used is as follows: OlsrRoutingHelper olsr; InternetStackHelper stack; stack.SetRoutingProtocol (olsr); stack.Install (nodes); So, users still use Install: Create is used internally by InternetStackHelper::Install. Does this answer your question ? Mathieu From mathieu.lacage at sophia.inria.fr Wed Sep 16 23:53:34 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 08:53:34 +0200 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <1253017732.14583.70.camel@diese.inria.fr> <0c57d21cd59b9ebb92d13a0014a160ac@tomh.org> Message-ID: <1253170414.24392.87.camel@diese.inria.fr> On Wed, 2009-09-16 at 17:26 +0100, Gustavo Carneiro wrote: > > One thing that I noticed is that if we aim for such an > alignment, there > will be cases in which we need to manipulate a packet > (push or strip an > IPv4 header) just for providing to a trace source. > This is because, at > different locations in the IP layer, the packet may > have a header or it or > may not. Such a manipulation doesn't seem to be a > good idea in general (to > do work to massage input for a trace source to which > nothing may be > connected) because AddHeader triggers a deep copy. > > Should the priority instead be to avoid deep copies > for the sake of > tracing? > > > I am only arguing that at any given layer trace sources should > be given the header, which already exists separately at that > layer. If you look closely, you'll see that at IPv4 layer the > Ipv4Header is already available somewhere within the > send/deliver/forward methods. In the receive method, the > Ipv4Header will be removed from the received packet sooner or > later in that function--it makes no difference to remove it > sooner rather than later. In the send method, the Ipv4Header > is built inside the method and added to the packet before > transmission--calling the Tx trace source before adding the > header poses no performance penalty. Likewise, in forwarding > function the header exists separately and is added inside the > method. > > To summarize, I argue that it is often useful for trace > callbacks to get access to the IP header, and that getting > this IP header does not add any overhead. The way we have done that in wifi is to pass all the information down to the pcap writer through the trace hooks and serialize the header in the pcap writer directly so that you get the best of both worlds. The cost is some extra header serialization code duplication... Mathieu > From mathieu.lacage at sophia.inria.fr Wed Sep 16 23:56:47 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 08:56:47 +0200 Subject: [Ns-developers] Development of new routing protocol In-Reply-To: <200909161153.45008.boyko@iitp.ru> References: <5c2d9c8b0909101839n6ae72954rd7e54830bf4a90e5@mail.gmail.com> <5c2d9c8b0909151348q5f7b2557ufb7756689074b13b@mail.gmail.com> <200909161153.45008.boyko@iitp.ru> Message-ID: <1253170607.24392.89.camel@diese.inria.fr> On Wed, 2009-09-16 at 11:53 +0400, Pavel Boyko wrote: > We just interested in growing aodv model user base, nothing else. I don't > have specific test cases and time frames for you. Also I don't have specific > plans to merge aodv model into the ns-3 mainline -- that depends on users > feedback. As a general comment, I should point out that it's better for you to merge early if you can because the cost of early merges is much lower than that of late merges. i.e., if your code appears to work and goes through review, why can't we merge it in right after ns-3.6 is out ? Mathieu From mathieu.lacage at sophia.inria.fr Thu Sep 17 00:33:57 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 09:33:57 +0200 Subject: [Ns-developers] ns-3.5.1 release? In-Reply-To: <1253002048.14583.10.camel@diese.inria.fr> References: <4AADC143.8060305@tomh.org> <1253002048.14583.10.camel@diese.inria.fr> Message-ID: <1253172837.24392.93.camel@diese.inria.fr> The code is now there: http://code.nsnam.org/mathieu/ns-3.5.1 I am waiting for sam and florian to do an nsc 0.6 release and, once this is done, I will attempt 3.5.1. Mathieu On Tue, 2009-09-15 at 10:07 +0200, Mathieu Lacage wrote: > hi tom, > > I will try to put together a branch with your suggested fixes tomorrow. > > Mathieu > > > On Sun, 2009-09-13 at 21:06 -0700, Tom Henderson wrote: > > I'd like to propose an ns-3.5.1 release that includes the following > > changesets since ns-3.5. I suggest to post an ns-allinone-3.5.1 release > > and an ns-3.5-to-ns-3.5.1.patch. > > > > Regarding nsc, it seems like we did not include a released version of > > nsc for the ns-3.5 release. If nsc can make a maintenance release now, > > we can include that; otherwise, I suggest that we just include the tip > > of nsc's development tree, to obtain the gcc-4.4 fixes. > > > > Bug fixes: > > --------- > > > > fdf71375766a: Bug 628: Virtual Net Device's DoDispose doesn't clean up > > properly; patch by Antti M?kel?. > > > > 7defe7a99e9c: fix bug preventing the sending of packets to a local IP > > address (bug 632) > > > > 258cf77942bc: emu device shouldn't be adding an FCS > > > > 7555c9a0564b: bug 627: Jakes Propagation Loss Model doesn't properly > > calculate signal loss > > > > f17f12944235: Bug 625: Wrong calculation of GetAccessGrantStart in > > DcfManager. > > > > 02bf728f7e39: bug 381: Wifi crashes on shutdown > > > > 6cd5056a8fe0: Fix first.py example > > > > 637b9cacd0b5: bug 642: allow multiple InternetStackHelpers to be > > instantiated > > > > 6e048d6486d8: Implement UdpSocketImpl::Close () > > > > 60cd412fa3dd: fix for bug 650 (PacketSocket Close() > > > > e33a677e8864: Reorder the #includes in ns3module_helpers.cc to solve > > Fedora 11 compilation error > > > > b251fb79becb: bug 639: Buffer::CopyData is buggy. > > > > 3fdb8f60a863: bug 654: avoid segfault with ConfigStore loading > > > > fef6ccee5897: Fixed erroneous first return of Normal Variable > > > > 5e4fb3918879: Fixed WifiMacHeader Print Control Characters bug 661 > > > > (bug 643 patch could also be included in this list, if it is pushed soon) > > > > Documentation (manual, doxygen) changesets: > > ------------- > > > > 36b78cddce4d > > 6dc56539a891 > > b57d5b1fe68e > > 04a9a7e9a624 > > 3d08aef4a581 > > ba5d6d52be7e > > > From mathieu.lacage at sophia.inria.fr Thu Sep 17 00:49:06 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 17 Sep 2009 09:49:06 +0200 Subject: [Ns-developers] ns-3 get-together Message-ID: <1253173746.24392.99.camel@diese.inria.fr> hi, Tom and I will be present at ROADS'09 (http://roads.mytestbed.net/): I will try to organize a small ns-3 get-together lunch on october, tuesday 13th, in the evening. If you want to talk about ns-3 during dinner, or chat over a beverage of your choice, please, let me know by email privately with information on how to contact you there (cellphone number ?). regards, Mathieu From gjcarneiro at gmail.com Thu Sep 17 02:27:39 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 17 Sep 2009 10:27:39 +0100 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> References: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> Message-ID: 2009/9/17 Duy Nguyen > Hi Gustavo, I just tested out your flow monitor and find it very useful. > However, I am not able to use it for multiple flows. I attach my test case > in this email. Maybe I make a mistake somewhere in my scripts, but I > could not figure it out, could you help me take a look? > > I attached many-flows.cc in this email. I set up 3x3 grid with 9 nodes > total, but you many increase it to however many nodes or flows you like. > Environment is a multi-hop adhoc with either olsr/aodv > My quick first impression, though I will look more carefully later, is that flow monitor is picking flows with destination address 10.0.1.255. But it should not be picking up any flows at all since your code appears to be using L2 sockets, and Flow Monitor at this moment only has IPv4 monitoring implemented. So I am confused. I'll get back to this later. [incidentally, why you use OLSR for L2 packets is beyond me]. > > Flow 1: node 0-> node 1 > Flow 2: node 2-> node 3 > Flow 3: node 4-> node 5 > Flow 4: node 6-> node 7 > > and this is many-flows.flowmo > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" > destinationPort="698" /> > destinationAddress="127.255.255.255" protocol="17" sourcePort="698" > destinationPort="698" / > > > Thank you for your time, > > Duy > > 2009/9/15 Gustavo Carneiro > > 2009/9/15 Tom Henderson >> >> > Gustavo, >> > Please clarify if I am mistaken, but here are the open issues with your >> > trace sources and the IP traces in general: >> > >> > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with >> your >> > new traces and with the modified m_dropTrace? >> > >> > My opinion is that it would be OK to align these; this change should not >> > cause a soft (undetected) error in users scripts, and you are already >> > modifying m_dropTrace. >> > >> >> Yes, I regret to modify m_dropTrace. On one hand I hat breaking >> API/ABI/behavior (either "soft" or "hard"), you know I really do. On the >> other hand if I had added a new MyAlternativeDrop trace I just know I >> would >> receive comments from you, Mathieu, or Craig saying that I was duplicating >> functionality, etc. Now txTrace and rxTrace modifications will break even >> more APIs. Programs will not even fail at runtime, just Config::Connect >> will have no effect due to non-matching Callback signature. No, I do >> _not_ >> like this, but if you want consistency I don't see any other option. >> >> >> > >> > 2) does the Packet passed to the trace sources have an IP header or not, >> > and is it important to have consistency across these traces? >> > >> > In your proposal, m_dropTrace and your new traces pass a Packet pointer >> > without IP header. I see that you have made sure that m_dropTrace is >> > consistent in that regard. However, m_txTrace/m_rxTrace Packet >> presently >> > includes the IP header. m_txTrace and m_rxTrace live right at the >> > boundary of the IPv4 model, so conceptually they are hit just before >> giving >> > to the outgoing device or just after receiving (before any logic is >> applied >> > to the packet contents). I do not feel strongly either way about >> whether >> > m_txTrace or m_rxTrace pass a packet with or without the IP header, so >> long >> > as it is documented which way it is, and so long as it is consistent >> within >> > the trace source itself. Are there other opinions on this? >> > >> >> I am also willing (not my preferred choice, but...) to go back the other >> way: make all trace sources, including the Drop and new ones, pass a >> packet >> with an IP header already serialized. Maybe performance won't be so >> great, >> but if it unblocks the merge then it may be worth the effort. I expect >> that >> at least PeekHeader should not be slow... >> >> >> > >> > 3) Future netfilter alignment, and placement of traces in general. >> > >> > You suggested in the ns-3-reviews thread that you thought it would be >> good >> > to place these traces after any corresponding netfilter hook has >> returned. >> > It seems like the new ones roughly map as follows: >> > m_sendOutgoingTrace -> POSTROUTING >> > m_unicastForward -> FORWARD (although only unicast forwarding) >> > m_localDeliver -> LOCAL_IN >> > >> > When netfilter is added, the trace sources may have to be moved in the >> code >> > slightly, which may slightly change the packets that they see. I don't >> > think this is a big deal right now. >> > >> > One design issue that probably needs to be considered now is how >> Netfilter >> > API is expected to be added. We are presently stripping the packet >> header >> > early in the IPv4 Receive process and adding it back just before sending >> it >> > out. So, packets passed to Netfilter will not have IP headers. With >> the >> > current APIs, Netfilter will have to separately handle a Ptr and >> > Ipv4Header and be able to pass back a modified IP header that will need >> to >> > go forward with the packet, and if the Netfilter client code expects to >> > mangle everything within a packed packet structure, that would mean >> doing >> > AddHeader(), mangle, RemoveHeader() which seems not so great. >> >> >> Correct. Maybe it is better for the Netfilter code to receive and return >> back also the IP header. It's probably more efficient too. This is >> basically what the Ipv4routingProtocol (at least the way I had implemented >> it initially, no idea if it has changed) did too: it received a packet >> without IP header plus the IP header, and it returned back a possibly >> modified packet plus possibly modified IP header. >> >> Thanks, >> >> -- >> Gustavo J. A. M. Carneiro >> INESC Porto, Telecommunications and Multimedia Unit >> "The universe is always one step beyond logic." -- Frank Herbert >> > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From gjcarneiro at gmail.com Thu Sep 17 02:30:11 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 17 Sep 2009 10:30:11 +0100 Subject: [Ns-developers] Ipv4RoutingHelper: Create vs Install? In-Reply-To: <1253169983.24392.80.camel@diese.inria.fr> References: <1253169983.24392.80.camel@diese.inria.fr> Message-ID: 2009/9/17 Mathieu Lacage > On Tue, 2009-09-15 at 17:49 +0100, Gustavo Carneiro wrote: > > Why the rename from OlsrRoutingHelper from Install () to Create (). This > > seems rather inconsistent with the usual method names for the helpers, > > no?... > > > The way it's expected to be used is as follows: > > OlsrRoutingHelper olsr; > InternetStackHelper stack; > > stack.SetRoutingProtocol (olsr); > stack.Install (nodes); > > So, users still use Install: Create is used internally by > InternetStackHelper::Install. > > Does this answer your question ? > Yes, and it's even properly documented. Silly me. Thanks, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From gjcarneiro at gmail.com Thu Sep 17 03:58:38 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 17 Sep 2009 11:58:38 +0100 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: References: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> Message-ID: 2009/9/17 Gustavo Carneiro > > > 2009/9/17 Duy Nguyen > >> Hi Gustavo, I just tested out your flow monitor and find it very useful. >> However, I am not able to use it for multiple flows. I attach my test case >> in this email. Maybe I make a mistake somewhere in my scripts, but I >> could not figure it out, could you help me take a look? >> >> I attached many-flows.cc in this email. I set up 3x3 grid with 9 nodes >> total, but you many increase it to however many nodes or flows you like. >> Environment is a multi-hop adhoc with either olsr/aodv >> > > My quick first impression, though I will look more carefully later, is that > flow monitor is picking flows with destination address 10.0.1.255. But it > should not be picking up any flows at all since your code appears to be > using L2 sockets, and Flow Monitor at this moment only has IPv4 monitoring > implemented. So I am confused. I'll get back to this later. > [incidentally, why you use OLSR for L2 packets is beyond me]. > Protocol 17 (UDP) port 698 is OLSR. Flow Monitor is picking up the OLSR packets as flows. I have not found a good robust way to detect broadcast packets yet, and Flow Monitor is not prepared to monitor broadcast/multicast flows. Nor does it monitor L2 flows. The Flow Monitor architecture allows it to be extended to monitor just about any layer, but it needs to be coded first. So far, only IPv4. Sorry. > > >> >> Flow 1: node 0-> node 1 >> Flow 2: node 2-> node 3 >> Flow 3: node 4-> node 5 >> Flow 4: node 6-> node 7 >> >> and this is many-flows.flowmo >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >> destinationPort="698" /> >> > destinationAddress="127.255.255.255" protocol="17" sourcePort="698" >> destinationPort="698" / >> >> >> Thank you for your time, >> >> Duy >> >> 2009/9/15 Gustavo Carneiro >> >> 2009/9/15 Tom Henderson >>> >>> > Gustavo, >>> > Please clarify if I am mistaken, but here are the open issues with your >>> > trace sources and the IP traces in general: >>> > >>> > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with >>> your >>> > new traces and with the modified m_dropTrace? >>> > >>> > My opinion is that it would be OK to align these; this change should >>> not >>> > cause a soft (undetected) error in users scripts, and you are already >>> > modifying m_dropTrace. >>> > >>> >>> Yes, I regret to modify m_dropTrace. On one hand I hat breaking >>> API/ABI/behavior (either "soft" or "hard"), you know I really do. On the >>> other hand if I had added a new MyAlternativeDrop trace I just know I >>> would >>> receive comments from you, Mathieu, or Craig saying that I was >>> duplicating >>> functionality, etc. Now txTrace and rxTrace modifications will break >>> even >>> more APIs. Programs will not even fail at runtime, just Config::Connect >>> will have no effect due to non-matching Callback signature. No, I do >>> _not_ >>> like this, but if you want consistency I don't see any other option. >>> >>> >>> > >>> > 2) does the Packet passed to the trace sources have an IP header or >>> not, >>> > and is it important to have consistency across these traces? >>> > >>> > In your proposal, m_dropTrace and your new traces pass a Packet pointer >>> > without IP header. I see that you have made sure that m_dropTrace is >>> > consistent in that regard. However, m_txTrace/m_rxTrace Packet >>> presently >>> > includes the IP header. m_txTrace and m_rxTrace live right at the >>> > boundary of the IPv4 model, so conceptually they are hit just before >>> giving >>> > to the outgoing device or just after receiving (before any logic is >>> applied >>> > to the packet contents). I do not feel strongly either way about >>> whether >>> > m_txTrace or m_rxTrace pass a packet with or without the IP header, so >>> long >>> > as it is documented which way it is, and so long as it is consistent >>> within >>> > the trace source itself. Are there other opinions on this? >>> > >>> >>> I am also willing (not my preferred choice, but...) to go back the other >>> way: make all trace sources, including the Drop and new ones, pass a >>> packet >>> with an IP header already serialized. Maybe performance won't be so >>> great, >>> but if it unblocks the merge then it may be worth the effort. I expect >>> that >>> at least PeekHeader should not be slow... >>> >>> >>> > >>> > 3) Future netfilter alignment, and placement of traces in general. >>> > >>> > You suggested in the ns-3-reviews thread that you thought it would be >>> good >>> > to place these traces after any corresponding netfilter hook has >>> returned. >>> > It seems like the new ones roughly map as follows: >>> > m_sendOutgoingTrace -> POSTROUTING >>> > m_unicastForward -> FORWARD (although only unicast forwarding) >>> > m_localDeliver -> LOCAL_IN >>> > >>> > When netfilter is added, the trace sources may have to be moved in the >>> code >>> > slightly, which may slightly change the packets that they see. I don't >>> > think this is a big deal right now. >>> > >>> > One design issue that probably needs to be considered now is how >>> Netfilter >>> > API is expected to be added. We are presently stripping the packet >>> header >>> > early in the IPv4 Receive process and adding it back just before >>> sending it >>> > out. So, packets passed to Netfilter will not have IP headers. With >>> the >>> > current APIs, Netfilter will have to separately handle a Ptr >>> and >>> > Ipv4Header and be able to pass back a modified IP header that will need >>> to >>> > go forward with the packet, and if the Netfilter client code expects to >>> > mangle everything within a packed packet structure, that would mean >>> doing >>> > AddHeader(), mangle, RemoveHeader() which seems not so great. >>> >>> >>> Correct. Maybe it is better for the Netfilter code to receive and return >>> back also the IP header. It's probably more efficient too. This is >>> basically what the Ipv4routingProtocol (at least the way I had >>> implemented >>> it initially, no idea if it has changed) did too: it received a packet >>> without IP header plus the IP header, and it returned back a possibly >>> modified packet plus possibly modified IP header. >>> >>> Thanks, >>> >>> -- >>> Gustavo J. A. M. Carneiro >>> INESC Porto, Telecommunications and Multimedia Unit >>> "The universe is always one step beyond logic." -- Frank Herbert >>> >> >> > > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From tomh at tomh.org Thu Sep 17 07:29:07 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 17 Sep 2009 07:29:07 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <1253169717.24392.76.camel@diese.inria.fr> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169717.24392.76.camel@diese.inria.fr> Message-ID: <4AB247B3.7070207@tomh.org> >> 2. NetAnim Animator Support >> >> There seems to be a philosophy-of-helper issue brewing regarding this. My >> opinion is that it is way too late in the release process for this kind of >> discussion to be taking place. It has been proposed that this feature could >> go into src/contrib until the helper questions are answered. I think this >> is okay. > > I did not follow the discussions but if there is really a philosophical > discussion going on, it does not sound like a good idea to merge it, > even in src/contrib, especially so late in the release cycle. What is > sad is that this code has been waiting for review for quite a long time > so, we (those who review code) are mostly responsible for this lateness > in the discussion. I don't have any good input here: both options appear > to not be optimal. Maybe there is no philosophical discussion to have (I haven't seen a response to George's post here: http://mailman.isi.edu/pipermail/ns-developers/2009-September/006555.html and no one else has publicly reviewed this patch set) These are the two main issues I would like to see handled with the helpers: 1) add support for IPv6 (will we be overloading existing methods or changing method names?) 2) resolve how animation coordinates are to be stored in helpers/nodes, if at all. BoundingBox () to me seems to be a method more appropriate to give to the AnimationHelper than to each topology object. For instance, something like: - AnimationInterface::BoundingBox () // sets bounding box for whole canvas - Dumbbell::CanvasLayout (..) // assign canvas coordinates to dumbbell objects. - rename NodeLocation aggregated object to CanvasLocation But since it is late to agree to this, if we put these in src/contrib for this release and flagged the helper API as being provisional in the provided example scripts, I think we wouldn't be too disruptive to future users, so it seems a suitable compromise to me. Tom From tomh at tomh.org Thu Sep 17 07:33:18 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 17 Sep 2009 07:33:18 -0700 Subject: [Ns-developers] Last Comments on Merge Queue for Ns-3.6 Release In-Reply-To: <1253169878.24392.78.camel@diese.inria.fr> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169878.24392.78.camel@diese.inria.fr> Message-ID: <4AB248AE.1070909@tomh.org> Mathieu Lacage wrote: > On Wed, 2009-09-16 at 13:35 -0700, craigdo at ee.washington.edu wrote: > >> The trick to this is going to be "an appropriately generic trace source >> useful to the animator." > > > [wifi maintainer on] > > Could you point me to the relevant proposed change so that I can make > sure that it's not a killer for wifi ? > http://codereview.appspot.com/117051/patch/51/1026 It is not generic; I don't know if it can be made to be generic across device types. - Tom From craigdo at ee.washington.edu Thu Sep 17 12:08:45 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 17 Sep 2009 12:08:45 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <4AB247B3.7070207@tomh.org> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169717.24392.76.camel@diese.inria.fr> <4AB247B3.7070207@tomh.org> Message-ID: > Maybe there is no philosophical discussion to have (I haven't seen a > response to George's post here: > http://mailman.isi.edu/pipermail/ns-developers/2009-September/ > 006555.html > and no one else has publicly reviewed this patch set) Well, I haven't responded because it seems like it would result in a long discussion about the direction to take in designing helper "stock objects." I don't like the current approach very much (PointToPointHelper::InstallStar) and I would like to also reopen a discussion about helper base classes as well. I think we need to talk about this stuff, but IMO this isn't something that is going to be resolved in a few days, so I am holding my peace for now. > These are the two main issues I would like to see handled > with the helpers: > > 1) add support for IPv6 (will we be overloading existing methods or > changing method names?) > > 2) resolve how animation coordinates are to be stored in > helpers/nodes, > if at all. BoundingBox () to me seems to be a method more > appropriate > to give to the AnimationHelper than to each topology object. For > instance, something like: > - AnimationInterface::BoundingBox () // sets bounding box > for whole > canvas > - Dumbbell::CanvasLayout (..) // assign canvas coordinates to > dumbbell objects. > - rename NodeLocation aggregated object to CanvasLocation It seems to me that the simulator proper shouldn't know or care about bounding boxes on rendering canvases. It seems to me that the simulation part should only know about the physical positions that are being simulated and the animator should be responsible for projecting those positions onto its canvas. If the spatial positions need to be constrained in some way, then they should have their simulated physical position constrained. > But since it is late to agree to this, if we put these in src/contrib > for this release and flagged the helper API as being > provisional in the > provided example scripts, I think we wouldn't be too disruptive to > future users, so it seems a suitable compromise to me. Yes. I thought we had previously agreed that this was the best approach for now. -- Craig From craigdo at ee.washington.edu Thu Sep 17 12:20:33 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 17 Sep 2009 12:20:33 -0700 Subject: [Ns-developers] Last Comments on Merge Queue for Ns-3.6 Release In-Reply-To: <4AB248AE.1070909@tomh.org> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169878.24392.78.camel@diese.inria.fr> <4AB248AE.1070909@tomh.org> Message-ID: > > [wifi maintainer on] > > > > Could you point me to the relevant proposed change so that > I can make > > sure that it's not a killer for wifi ? > > > > http://codereview.appspot.com/117051/patch/51/1026 > > It is not generic; I don't know if it can be made to be > generic across > device types. Okay, then I misunderstood what was required. In this case, the trace source should definitely not go into the generic channel class, but into the appropriate specific channel class (PointToPointChannel?). The trace hook would then look more like, "/ChannelList/*/$ns3::PointToPointChannel/SpecificTraceSource" -- Craig From riley at ece.gatech.edu Thu Sep 17 12:29:25 2009 From: riley at ece.gatech.edu (George Riley) Date: Thu, 17 Sep 2009 15:29:25 -0400 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169717.24392.76.camel@diese.inria.fr> <4AB247B3.7070207@tomh.org> Message-ID: <47F3D6D1-6DB6-4E36-B5F9-35D1AD5CA6A5@ece.gatech.edu> > > Maybe there is no philosophical discussion to have (I haven't seen a >> response to George's post here: >> http://mailman.isi.edu/pipermail/ns-developers/2009-September/ >> 006555.html >> and no one else has publicly reviewed this patch set) > > Well, I haven't responded because it seems like it would result in a > long > discussion about the direction to take in designing helper "stock > objects." > I don't like the current approach very much > (PointToPointHelper::InstallStar) and I would like to also reopen a > discussion about helper base classes as well. > > I think we need to talk about this stuff, but IMO this isn't > something that > is going to be resolved in a few days, so I am holding my peace for > now. I agree we need to resolve this, but not before this release. > >> These are the two main issues I would like to see handled >> with the helpers: >> >> 1) add support for IPv6 (will we be overloading existing methods or >> changing method names?) >> >> 2) resolve how animation coordinates are to be stored in >> helpers/nodes, >> if at all. BoundingBox () to me seems to be a method more >> appropriate >> to give to the AnimationHelper than to each topology object. For >> instance, something like: >> - AnimationInterface::BoundingBox () // sets bounding box >> for whole >> canvas >> - Dumbbell::CanvasLayout (..) // assign canvas coordinates to >> dumbbell objects. >> - rename NodeLocation aggregated object to CanvasLocation > > It seems to me that the simulator proper shouldn't know or care about > bounding boxes on rendering canvases. It seems to me that the > simulation > part should only know about the physical positions that are being > simulated > and the animator should be responsible for projecting those > positions onto > its canvas. If the spatial positions need to be constrained in some > way, > then they should have their simulated physical position constrained. Sorry Craig but I disagree; our beautiful design is such that any Object can have aggregated to it any other object without regard to the functionality of the aggregated object. Are you saying you object to me doing exactly this? I'm having trouble imagining an objection to using our object system as designed. If you don't want node locations associated with your nodes, then don't include them. Problem solved. > >> But since it is late to agree to this, if we put these in src/contrib >> for this release and flagged the helper API as being >> provisional in the >> provided example scripts, I think we wouldn't be too disruptive to >> future users, so it seems a suitable compromise to me. > > Yes. I thought we had previously agreed that this was the best > approach for > now. > > -- Craig > > > From craigdo at ee.washington.edu Thu Sep 17 13:06:38 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 17 Sep 2009 13:06:38 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <47F3D6D1-6DB6-4E36-B5F9-35D1AD5CA6A5@ece.gatech.edu> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169717.24392.76.camel@diese.inria.fr> <4AB247B3.7070207@tomh.org> <47F3D6D1-6DB6-4E36-B5F9-35D1AD5CA6A5@ece.gatech.edu> Message-ID: <03F0161FD56B4300B08290E28D039655@CRAIGVAIO> [ ... ] > > It seems to me that the simulator proper shouldn't know or > care about > > bounding boxes on rendering canvases. It seems to me that the > > simulation > > part should only know about the physical positions that are being > > simulated > > and the animator should be responsible for projecting those > > positions onto > > its canvas. If the spatial positions need to be > constrained in some > > way, > > then they should have their simulated physical position constrained. > > Sorry Craig but I disagree; our beautiful design is such that any > Object can have aggregated > to it any other object without regard to the functionality of the > aggregated > object. Are you saying you object to me doing exactly this? I'm > having trouble > imagining an objection to using our object system as > designed. If you > don't > want node locations associated with your nodes, then don't > include them. > Problem solved. It looks to me like there is a method called BoundingBox in a topology object. It's not intuitively obvious if this is a kind of constrained static mobility model for nodes or a layout function for arranging bitmaps on a canvas. IMO, if it's a static mobility model, it should be a kind of mobility model. IMO, if it's a layout function for arranging bitmaps on a canvas, it shouldn't be in a topology object, it should be in a canvas layout object. If that layout object wants to aggregate something to a node, then yes, our beautiful design allows it. IMO, that last part is the really good reason for pulling stock topology stuff (CreateStar) out of low level helpers and making them first-class objects -- so you can get at the nodes and do that kind of aggregation. I'm not objecting to using our system the way it was designed. I'm objecting to putting "view" code in the "model" (think MVC design pattern). I agree with Tom. -- Craig From riley at ece.gatech.edu Thu Sep 17 13:13:38 2009 From: riley at ece.gatech.edu (George Riley) Date: Thu, 17 Sep 2009 16:13:38 -0400 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <03F0161FD56B4300B08290E28D039655@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169717.24392.76.camel@diese.inria.fr> <4AB247B3.7070207@tomh.org> <47F3D6D1-6DB6-4E36-B5F9-35D1AD5CA6A5@ece.gatech.edu> <03F0161FD56B4300B08290E28D039655@CRAIGVAIO> Message-ID: <06D208B2-65B3-446F-86DF-631CC21616ED@ece.gatech.edu> > > Problem solved. > > It looks to me like there is a method called BoundingBox in a topology > object. It's not intuitively obvious if this is a kind of constrained > static mobility model for nodes or a layout function for arranging > bitmaps > on a canvas. Ok, I buy that; this could easily be moved to somewhere more reasonable, but I don't want to do that just now, agree? > > IMO, if it's a static mobility model, it should be a kind of > mobility model. > > IMO, if it's a layout function for arranging bitmaps on a canvas, it > shouldn't be in a topology object, it should be in a canvas layout > object. > If that layout object wants to aggregate something to a node, then > yes, our > beautiful design allows it. > > IMO, that last part is the really good reason for pulling stock > topology > stuff (CreateStar) out of low level helpers and making them first- > class > objects -- so you can get at the nodes and do that kind of > aggregation. > > I'm not objecting to using our system the way it was designed. I'm > objecting to putting "view" code in the "model" (think MVC design > pattern). I don't think we have specified the MVC design pattern as the corrrect model for ns-3 have we? George From craigdo at ee.washington.edu Thu Sep 17 13:41:33 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 17 Sep 2009 13:41:33 -0700 Subject: [Ns-developers] Current Merge Queue for Ns-3.6 Release In-Reply-To: <06D208B2-65B3-446F-86DF-631CC21616ED@ece.gatech.edu> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169717.24392.76.camel@diese.inria.fr> <4AB247B3.7070207@tomh.org> <47F3D6D1-6DB6-4E36-B5F9-35D1AD5CA6A5@ece.gatech.edu> <03F0161FD56B4300B08290E28D039655@CRAIGVAIO> <06D208B2-65B3-446F-86DF-631CC21616ED@ece.gatech.edu> Message-ID: <811E1D10A39F48FE824857F9256E0432@CRAIGVAIO> > -----Original Message----- > From: George Riley [mailto:riley at ece.gatech.edu] > Sent: Thursday, September 17, 2009 1:14 PM > To: craigdo at u.washington.edu > Cc: 'Tom Henderson'; 'Mathieu Lacage'; ns-developers at ISI.EDU > Subject: Re: [Ns-developers] Current Merge Queue for Ns-3.6 Release > > > > > Problem solved. > > > > It looks to me like there is a method called BoundingBox in > a topology > > object. It's not intuitively obvious if this is a kind of > constrained > > static mobility model for nodes or a layout function for arranging > > bitmaps > > on a canvas. > Ok, I buy that; this could easily be moved to somewhere more > reasonable, > but I don't want to do that just now, agree? Yes. That, I think, is one of the reasons Tom is asking to put some of this in src/contrib. Again, an API question regarding what stays in where, and comes and goes when, comes up. > > IMO, if it's a static mobility model, it should be a kind of > > mobility model. > > > > IMO, if it's a layout function for arranging bitmaps on a canvas, it > > shouldn't be in a topology object, it should be in a canvas layout > > object. > > If that layout object wants to aggregate something to a node, then > > yes, our > > beautiful design allows it. > > > > IMO, that last part is the really good reason for pulling stock > > topology > > stuff (CreateStar) out of low level helpers and making them first- > > class > > objects -- so you can get at the nodes and do that kind of > > aggregation. > > > > I'm not objecting to using our system the way it was designed. I'm > > objecting to putting "view" code in the "model" (think MVC design > > pattern). > I don't think we have specified the MVC design pattern as the > corrrect > model > for ns-3 have we? No. We haven't codified other well-known software engineering practices either. I think it's the job of maintainers to bring that kind of stuff up in reviews, though. I wasn't suggesting that we demand people use MVC. I was illustrating a modularity question by referencing a well-known architectural pattern that has worked very well in decoupling similar things for the last thirty years (it first appeared in Smalltalk-80). YMMV. From dnlove at gmail.com Thu Sep 17 21:55:13 2009 From: dnlove at gmail.com (Duy Nguyen) Date: Thu, 17 Sep 2009 21:55:13 -0700 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: References: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> Message-ID: <70f6a1ed0909172155j63fdd4bbh22d8815d435680d9@mail.gmail.com> I am still not sure what you mean by Layer2 sockets. So you mean, I should create sockets at the link layer for olsr? it's the same for aodv? I am new to ns3, I am not sure how to do it yet, could you point me to some example scripts? Basically, I create sockets using ns3::PacketSocketFactory. I install internet stack and Ipv4 interface for each node and assign each node with ipv4 address. Maybe you could give me some pointers. Duy 2009/9/17 Gustavo Carneiro > > > 2009/9/17 Gustavo Carneiro > >> >> >> 2009/9/17 Duy Nguyen >> >>> Hi Gustavo, I just tested out your flow monitor and find it very useful. >>> However, I am not able to use it for multiple flows. I attach my test case >>> in this email. Maybe I make a mistake somewhere in my scripts, but I >>> could not figure it out, could you help me take a look? >>> >>> I attached many-flows.cc in this email. I set up 3x3 grid with 9 nodes >>> total, but you many increase it to however many nodes or flows you like. >>> Environment is a multi-hop adhoc with either olsr/aodv >>> >> >> My quick first impression, though I will look more carefully later, is >> that flow monitor is picking flows with destination address 10.0.1.255. But >> it should not be picking up any flows at all since your code appears to be >> using L2 sockets, and Flow Monitor at this moment only has IPv4 monitoring >> implemented. So I am confused. I'll get back to this later. >> [incidentally, why you use OLSR for L2 packets is beyond me]. >> > > Protocol 17 (UDP) port 698 is OLSR. Flow Monitor is picking up the OLSR > packets as flows. I have not found a good robust way to detect broadcast > packets yet, and Flow Monitor is not prepared to monitor broadcast/multicast > flows. Nor does it monitor L2 flows. The Flow Monitor architecture allows > it to be extended to monitor just about any layer, but it needs to be coded > first. So far, only IPv4. Sorry. > > >> >> >>> >>> Flow 1: node 0-> node 1 >>> Flow 2: node 2-> node 3 >>> Flow 3: node 4-> node 5 >>> Flow 4: node 6-> node 7 >>> >>> and this is many-flows.flowmo >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>> destinationPort="698" /> >>> >> destinationAddress="127.255.255.255" protocol="17" sourcePort="698" >>> destinationPort="698" / >>> >>> >>> Thank you for your time, >>> >>> Duy >>> >>> 2009/9/15 Gustavo Carneiro >>> >>> 2009/9/15 Tom Henderson >>>> >>>> > Gustavo, >>>> > Please clarify if I am mistaken, but here are the open issues with >>>> your >>>> > trace sources and the IP traces in general: >>>> > >>>> > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with >>>> your >>>> > new traces and with the modified m_dropTrace? >>>> > >>>> > My opinion is that it would be OK to align these; this change should >>>> not >>>> > cause a soft (undetected) error in users scripts, and you are already >>>> > modifying m_dropTrace. >>>> > >>>> >>>> Yes, I regret to modify m_dropTrace. On one hand I hat breaking >>>> API/ABI/behavior (either "soft" or "hard"), you know I really do. On >>>> the >>>> other hand if I had added a new MyAlternativeDrop trace I just know I >>>> would >>>> receive comments from you, Mathieu, or Craig saying that I was >>>> duplicating >>>> functionality, etc. Now txTrace and rxTrace modifications will break >>>> even >>>> more APIs. Programs will not even fail at runtime, just Config::Connect >>>> will have no effect due to non-matching Callback signature. No, I do >>>> _not_ >>>> like this, but if you want consistency I don't see any other option. >>>> >>>> >>>> > >>>> > 2) does the Packet passed to the trace sources have an IP header or >>>> not, >>>> > and is it important to have consistency across these traces? >>>> > >>>> > In your proposal, m_dropTrace and your new traces pass a Packet >>>> pointer >>>> > without IP header. I see that you have made sure that m_dropTrace is >>>> > consistent in that regard. However, m_txTrace/m_rxTrace Packet >>>> presently >>>> > includes the IP header. m_txTrace and m_rxTrace live right at the >>>> > boundary of the IPv4 model, so conceptually they are hit just before >>>> giving >>>> > to the outgoing device or just after receiving (before any logic is >>>> applied >>>> > to the packet contents). I do not feel strongly either way about >>>> whether >>>> > m_txTrace or m_rxTrace pass a packet with or without the IP header, so >>>> long >>>> > as it is documented which way it is, and so long as it is consistent >>>> within >>>> > the trace source itself. Are there other opinions on this? >>>> > >>>> >>>> I am also willing (not my preferred choice, but...) to go back the other >>>> way: make all trace sources, including the Drop and new ones, pass a >>>> packet >>>> with an IP header already serialized. Maybe performance won't be so >>>> great, >>>> but if it unblocks the merge then it may be worth the effort. I expect >>>> that >>>> at least PeekHeader should not be slow... >>>> >>>> >>>> > >>>> > 3) Future netfilter alignment, and placement of traces in general. >>>> > >>>> > You suggested in the ns-3-reviews thread that you thought it would be >>>> good >>>> > to place these traces after any corresponding netfilter hook has >>>> returned. >>>> > It seems like the new ones roughly map as follows: >>>> > m_sendOutgoingTrace -> POSTROUTING >>>> > m_unicastForward -> FORWARD (although only unicast forwarding) >>>> > m_localDeliver -> LOCAL_IN >>>> > >>>> > When netfilter is added, the trace sources may have to be moved in the >>>> code >>>> > slightly, which may slightly change the packets that they see. I >>>> don't >>>> > think this is a big deal right now. >>>> > >>>> > One design issue that probably needs to be considered now is how >>>> Netfilter >>>> > API is expected to be added. We are presently stripping the packet >>>> header >>>> > early in the IPv4 Receive process and adding it back just before >>>> sending it >>>> > out. So, packets passed to Netfilter will not have IP headers. With >>>> the >>>> > current APIs, Netfilter will have to separately handle a Ptr >>>> and >>>> > Ipv4Header and be able to pass back a modified IP header that will >>>> need to >>>> > go forward with the packet, and if the Netfilter client code expects >>>> to >>>> > mangle everything within a packed packet structure, that would mean >>>> doing >>>> > AddHeader(), mangle, RemoveHeader() which seems not so great. >>>> >>>> >>>> Correct. Maybe it is better for the Netfilter code to receive and >>>> return >>>> back also the IP header. It's probably more efficient too. This is >>>> basically what the Ipv4routingProtocol (at least the way I had >>>> implemented >>>> it initially, no idea if it has changed) did too: it received a packet >>>> without IP header plus the IP header, and it returned back a possibly >>>> modified packet plus possibly modified IP header. >>>> >>>> Thanks, >>>> >>>> -- >>>> Gustavo J. A. M. Carneiro >>>> INESC Porto, Telecommunications and Multimedia Unit >>>> "The universe is always one step beyond logic." -- Frank Herbert >>>> >>> >>> >> >> >> -- >> Gustavo J. A. M. Carneiro >> INESC Porto, Telecommunications and Multimedia Unit >> "The universe is always one step beyond logic." -- Frank Herbert >> > > > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > From mathieu.lacage at sophia.inria.fr Thu Sep 17 23:08:45 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 18 Sep 2009 08:08:45 +0200 Subject: [Ns-developers] Last Comments on Merge Queue for Ns-3.6 Release In-Reply-To: References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <05EB7AAFF69543C8A5C48EF1EDE58698@CRAIGVAIO> <2C39C00F2B1F4605B4CD3696B4E1A011@CRAIGVAIO> <1253169878.24392.78.camel@diese.inria.fr> <4AB248AE.1070909@tomh.org> Message-ID: <1253254125.9414.0.camel@diese.inria.fr> On Thu, 2009-09-17 at 12:20 -0700, craigdo at ee.washington.edu wrote: > > > [wifi maintainer on] > > > > > > Could you point me to the relevant proposed change so that > > I can make > > > sure that it's not a killer for wifi ? > > > > > > > http://codereview.appspot.com/117051/patch/51/1026 > > > > It is not generic; I don't know if it can be made to be > > generic across > > device types. > > Okay, then I misunderstood what was required. > > In this case, the trace source should definitely not go into the generic > channel class, but into the appropriate specific channel class > (PointToPointChannel?). The trace hook would then look more like, > > "/ChannelList/*/$ns3::PointToPointChannel/SpecificTraceSource" Which, as far as I can see, is exactly what is done in the patchset pointed out by tom. So, +1 with craig Mathieu From gjcarneiro at gmail.com Fri Sep 18 04:04:59 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 18 Sep 2009 12:04:59 +0100 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: <70f6a1ed0909172155j63fdd4bbh22d8815d435680d9@mail.gmail.com> References: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> <70f6a1ed0909172155j63fdd4bbh22d8815d435680d9@mail.gmail.com> Message-ID: 2009/9/18 Duy Nguyen > I am still not sure what you mean by Layer2 sockets. So you mean, I should > create sockets at the link layer for olsr? it's the same for aodv? I am > new to ns3, I am not sure how to do it yet, could you point me to some > example scripts? > > Basically, I create sockets using ns3::PacketSocketFactory. I install > internet stack and Ipv4 interface for each node and assign each node with > ipv4 address. > Maybe you could give me some pointers. > You need to use UdpSocketFactory and InetSocketAddress. I am working on a Python script for demonstrating Wifi+OLSR+FlowMonitor. Unfortunately it seems OLSR is currently broken in ns-3-dev, so you'll have to wait until the problem is sorted out. Meanwhile, I attach my script... > > Duy > > > 2009/9/17 Gustavo Carneiro > >> >> >> 2009/9/17 Gustavo Carneiro >> >>> >>> >>> 2009/9/17 Duy Nguyen >>> >>>> Hi Gustavo, I just tested out your flow monitor and find it very >>>> useful. However, I am not able to use it for multiple flows. I attach my >>>> test case in this email. Maybe I make a mistake somewhere in my scripts, >>>> but I could not figure it out, could you help me take a look? >>>> >>>> I attached many-flows.cc in this email. I set up 3x3 grid with 9 nodes >>>> total, but you many increase it to however many nodes or flows you like. >>>> Environment is a multi-hop adhoc with either olsr/aodv >>>> >>> >>> My quick first impression, though I will look more carefully later, is >>> that flow monitor is picking flows with destination address 10.0.1.255. But >>> it should not be picking up any flows at all since your code appears to be >>> using L2 sockets, and Flow Monitor at this moment only has IPv4 monitoring >>> implemented. So I am confused. I'll get back to this later. >>> [incidentally, why you use OLSR for L2 packets is beyond me]. >>> >> >> Protocol 17 (UDP) port 698 is OLSR. Flow Monitor is picking up the OLSR >> packets as flows. I have not found a good robust way to detect broadcast >> packets yet, and Flow Monitor is not prepared to monitor broadcast/multicast >> flows. Nor does it monitor L2 flows. The Flow Monitor architecture allows >> it to be extended to monitor just about any layer, but it needs to be coded >> first. So far, only IPv4. Sorry. >> >> >>> >>> >>>> >>>> Flow 1: node 0-> node 1 >>>> Flow 2: node 2-> node 3 >>>> Flow 3: node 4-> node 5 >>>> Flow 4: node 6-> node 7 >>>> >>>> and this is many-flows.flowmo >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>> destinationPort="698" /> >>>> >>> destinationAddress="127.255.255.255" protocol="17" sourcePort="698" >>>> destinationPort="698" / >>>> >>>> >>>> Thank you for your time, >>>> >>>> Duy >>>> >>>> 2009/9/15 Gustavo Carneiro >>>> >>>> 2009/9/15 Tom Henderson >>>>> >>>>> > Gustavo, >>>>> > Please clarify if I am mistaken, but here are the open issues with >>>>> your >>>>> > trace sources and the IP traces in general: >>>>> > >>>>> > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them with >>>>> your >>>>> > new traces and with the modified m_dropTrace? >>>>> > >>>>> > My opinion is that it would be OK to align these; this change should >>>>> not >>>>> > cause a soft (undetected) error in users scripts, and you are already >>>>> > modifying m_dropTrace. >>>>> > >>>>> >>>>> Yes, I regret to modify m_dropTrace. On one hand I hat breaking >>>>> API/ABI/behavior (either "soft" or "hard"), you know I really do. On >>>>> the >>>>> other hand if I had added a new MyAlternativeDrop trace I just know I >>>>> would >>>>> receive comments from you, Mathieu, or Craig saying that I was >>>>> duplicating >>>>> functionality, etc. Now txTrace and rxTrace modifications will break >>>>> even >>>>> more APIs. Programs will not even fail at runtime, just >>>>> Config::Connect >>>>> will have no effect due to non-matching Callback signature. No, I do >>>>> _not_ >>>>> like this, but if you want consistency I don't see any other option. >>>>> >>>>> >>>>> > >>>>> > 2) does the Packet passed to the trace sources have an IP header or >>>>> not, >>>>> > and is it important to have consistency across these traces? >>>>> > >>>>> > In your proposal, m_dropTrace and your new traces pass a Packet >>>>> pointer >>>>> > without IP header. I see that you have made sure that m_dropTrace is >>>>> > consistent in that regard. However, m_txTrace/m_rxTrace Packet >>>>> presently >>>>> > includes the IP header. m_txTrace and m_rxTrace live right at the >>>>> > boundary of the IPv4 model, so conceptually they are hit just before >>>>> giving >>>>> > to the outgoing device or just after receiving (before any logic is >>>>> applied >>>>> > to the packet contents). I do not feel strongly either way about >>>>> whether >>>>> > m_txTrace or m_rxTrace pass a packet with or without the IP header, >>>>> so long >>>>> > as it is documented which way it is, and so long as it is consistent >>>>> within >>>>> > the trace source itself. Are there other opinions on this? >>>>> > >>>>> >>>>> I am also willing (not my preferred choice, but...) to go back the >>>>> other >>>>> way: make all trace sources, including the Drop and new ones, pass a >>>>> packet >>>>> with an IP header already serialized. Maybe performance won't be so >>>>> great, >>>>> but if it unblocks the merge then it may be worth the effort. I expect >>>>> that >>>>> at least PeekHeader should not be slow... >>>>> >>>>> >>>>> > >>>>> > 3) Future netfilter alignment, and placement of traces in general. >>>>> > >>>>> > You suggested in the ns-3-reviews thread that you thought it would be >>>>> good >>>>> > to place these traces after any corresponding netfilter hook has >>>>> returned. >>>>> > It seems like the new ones roughly map as follows: >>>>> > m_sendOutgoingTrace -> POSTROUTING >>>>> > m_unicastForward -> FORWARD (although only unicast forwarding) >>>>> > m_localDeliver -> LOCAL_IN >>>>> > >>>>> > When netfilter is added, the trace sources may have to be moved in >>>>> the code >>>>> > slightly, which may slightly change the packets that they see. I >>>>> don't >>>>> > think this is a big deal right now. >>>>> > >>>>> > One design issue that probably needs to be considered now is how >>>>> Netfilter >>>>> > API is expected to be added. We are presently stripping the packet >>>>> header >>>>> > early in the IPv4 Receive process and adding it back just before >>>>> sending it >>>>> > out. So, packets passed to Netfilter will not have IP headers. With >>>>> the >>>>> > current APIs, Netfilter will have to separately handle a Ptr >>>>> and >>>>> > Ipv4Header and be able to pass back a modified IP header that will >>>>> need to >>>>> > go forward with the packet, and if the Netfilter client code expects >>>>> to >>>>> > mangle everything within a packed packet structure, that would mean >>>>> doing >>>>> > AddHeader(), mangle, RemoveHeader() which seems not so great. >>>>> >>>>> >>>>> Correct. Maybe it is better for the Netfilter code to receive and >>>>> return >>>>> back also the IP header. It's probably more efficient too. This is >>>>> basically what the Ipv4routingProtocol (at least the way I had >>>>> implemented >>>>> it initially, no idea if it has changed) did too: it received a packet >>>>> without IP header plus the IP header, and it returned back a possibly >>>>> modified packet plus possibly modified IP header. >>>>> >>>>> Thanks, >>>>> >>>>> -- >>>>> Gustavo J. A. M. Carneiro >>>>> INESC Porto, Telecommunications and Multimedia Unit >>>>> "The universe is always one step beyond logic." -- Frank Herbert >>>>> >>>> >>>> >>> >>> >>> -- >>> Gustavo J. A. M. Carneiro >>> INESC Porto, Telecommunications and Multimedia Unit >>> "The universe is always one step beyond logic." -- Frank Herbert >>> >> >> >> >> -- >> Gustavo J. A. M. Carneiro >> INESC Porto, Telecommunications and Multimedia Unit >> "The universe is always one step beyond logic." -- Frank Herbert >> > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- A non-text attachment was scrubbed... Name: wifi-olsr-flowmon.py Type: text/x-python Size: 6339 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090918/fda0e798/wifi-olsr-flowmon-0001.py From gjcarneiro at gmail.com Fri Sep 18 04:30:25 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 18 Sep 2009 12:30:25 +0100 Subject: [Ns-developers] Flow Monitor merge (Was: Current Merge Queue for Ns-3.6 Release) In-Reply-To: References: <70f6a1ed0909162020s435c9908v6ae24decb7f6550f@mail.gmail.com> <70f6a1ed0909172155j63fdd4bbh22d8815d435680d9@mail.gmail.com> Message-ID: 2009/9/18 Gustavo Carneiro > > > 2009/9/18 Duy Nguyen > >> I am still not sure what you mean by Layer2 sockets. So you mean, I >> should create sockets at the link layer for olsr? it's the same for aodv? >> I am new to ns3, I am not sure how to do it yet, could you point me to some >> example scripts? >> >> Basically, I create sockets using ns3::PacketSocketFactory. I install >> internet stack and Ipv4 interface for each node and assign each node with >> ipv4 address. >> Maybe you could give me some pointers. >> > > You need to use UdpSocketFactory and InetSocketAddress. > > I am working on a Python script for demonstrating Wifi+OLSR+FlowMonitor. > Unfortunately it seems OLSR is currently broken in ns-3-dev, so you'll have > to wait until the problem is sorted out. Meanwhile, I attach my script... > OK, it was a problem in the script after all. New example is now working and committed: http://code.nsnam.org/ns-3-dev/rev/d6bbde9c6712 > > >> >> Duy >> >> >> 2009/9/17 Gustavo Carneiro >> >>> >>> >>> 2009/9/17 Gustavo Carneiro >>> >>>> >>>> >>>> 2009/9/17 Duy Nguyen >>>> >>>>> Hi Gustavo, I just tested out your flow monitor and find it very >>>>> useful. However, I am not able to use it for multiple flows. I attach my >>>>> test case in this email. Maybe I make a mistake somewhere in my scripts, >>>>> but I could not figure it out, could you help me take a look? >>>>> >>>>> I attached many-flows.cc in this email. I set up 3x3 grid with 9 nodes >>>>> total, but you many increase it to however many nodes or flows you like. >>>>> Environment is a multi-hop adhoc with either olsr/aodv >>>>> >>>> >>>> My quick first impression, though I will look more carefully later, is >>>> that flow monitor is picking flows with destination address 10.0.1.255. But >>>> it should not be picking up any flows at all since your code appears to be >>>> using L2 sockets, and Flow Monitor at this moment only has IPv4 monitoring >>>> implemented. So I am confused. I'll get back to this later. >>>> [incidentally, why you use OLSR for L2 packets is beyond me]. >>>> >>> >>> Protocol 17 (UDP) port 698 is OLSR. Flow Monitor is picking up the OLSR >>> packets as flows. I have not found a good robust way to detect broadcast >>> packets yet, and Flow Monitor is not prepared to monitor broadcast/multicast >>> flows. Nor does it monitor L2 flows. The Flow Monitor architecture allows >>> it to be extended to monitor just about any layer, but it needs to be coded >>> first. So far, only IPv4. Sorry. >>> >>> >>>> >>>> >>>>> >>>>> Flow 1: node 0-> node 1 >>>>> Flow 2: node 2-> node 3 >>>>> Flow 3: node 4-> node 5 >>>>> Flow 4: node 6-> node 7 >>>>> >>>>> and this is many-flows.flowmo >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="10.0.1.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" /> >>>>> >>>> destinationAddress="127.255.255.255" protocol="17" sourcePort="698" >>>>> destinationPort="698" / >>>>> >>>>> >>>>> Thank you for your time, >>>>> >>>>> Duy >>>>> >>>>> 2009/9/15 Gustavo Carneiro >>>>> >>>>> 2009/9/15 Tom Henderson >>>>>> >>>>>> > Gustavo, >>>>>> > Please clarify if I am mistaken, but here are the open issues with >>>>>> your >>>>>> > trace sources and the IP traces in general: >>>>>> > >>>>>> > 1) do we add Ipv4Header to m_txTrace and m_rxTrace to align them >>>>>> with your >>>>>> > new traces and with the modified m_dropTrace? >>>>>> > >>>>>> > My opinion is that it would be OK to align these; this change should >>>>>> not >>>>>> > cause a soft (undetected) error in users scripts, and you are >>>>>> already >>>>>> > modifying m_dropTrace. >>>>>> > >>>>>> >>>>>> Yes, I regret to modify m_dropTrace. On one hand I hat breaking >>>>>> API/ABI/behavior (either "soft" or "hard"), you know I really do. On >>>>>> the >>>>>> other hand if I had added a new MyAlternativeDrop trace I just know I >>>>>> would >>>>>> receive comments from you, Mathieu, or Craig saying that I was >>>>>> duplicating >>>>>> functionality, etc. Now txTrace and rxTrace modifications will break >>>>>> even >>>>>> more APIs. Programs will not even fail at runtime, just >>>>>> Config::Connect >>>>>> will have no effect due to non-matching Callback signature. No, I do >>>>>> _not_ >>>>>> like this, but if you want consistency I don't see any other option. >>>>>> >>>>>> >>>>>> > >>>>>> > 2) does the Packet passed to the trace sources have an IP header or >>>>>> not, >>>>>> > and is it important to have consistency across these traces? >>>>>> > >>>>>> > In your proposal, m_dropTrace and your new traces pass a Packet >>>>>> pointer >>>>>> > without IP header. I see that you have made sure that m_dropTrace >>>>>> is >>>>>> > consistent in that regard. However, m_txTrace/m_rxTrace Packet >>>>>> presently >>>>>> > includes the IP header. m_txTrace and m_rxTrace live right at the >>>>>> > boundary of the IPv4 model, so conceptually they are hit just before >>>>>> giving >>>>>> > to the outgoing device or just after receiving (before any logic is >>>>>> applied >>>>>> > to the packet contents). I do not feel strongly either way about >>>>>> whether >>>>>> > m_txTrace or m_rxTrace pass a packet with or without the IP header, >>>>>> so long >>>>>> > as it is documented which way it is, and so long as it is consistent >>>>>> within >>>>>> > the trace source itself. Are there other opinions on this? >>>>>> > >>>>>> >>>>>> I am also willing (not my preferred choice, but...) to go back the >>>>>> other >>>>>> way: make all trace sources, including the Drop and new ones, pass a >>>>>> packet >>>>>> with an IP header already serialized. Maybe performance won't be so >>>>>> great, >>>>>> but if it unblocks the merge then it may be worth the effort. I >>>>>> expect that >>>>>> at least PeekHeader should not be slow... >>>>>> >>>>>> >>>>>> > >>>>>> > 3) Future netfilter alignment, and placement of traces in general. >>>>>> > >>>>>> > You suggested in the ns-3-reviews thread that you thought it would >>>>>> be good >>>>>> > to place these traces after any corresponding netfilter hook has >>>>>> returned. >>>>>> > It seems like the new ones roughly map as follows: >>>>>> > m_sendOutgoingTrace -> POSTROUTING >>>>>> > m_unicastForward -> FORWARD (although only unicast forwarding) >>>>>> > m_localDeliver -> LOCAL_IN >>>>>> > >>>>>> > When netfilter is added, the trace sources may have to be moved in >>>>>> the code >>>>>> > slightly, which may slightly change the packets that they see. I >>>>>> don't >>>>>> > think this is a big deal right now. >>>>>> > >>>>>> > One design issue that probably needs to be considered now is how >>>>>> Netfilter >>>>>> > API is expected to be added. We are presently stripping the packet >>>>>> header >>>>>> > early in the IPv4 Receive process and adding it back just before >>>>>> sending it >>>>>> > out. So, packets passed to Netfilter will not have IP headers. >>>>>> With the >>>>>> > current APIs, Netfilter will have to separately handle a Ptr >>>>>> and >>>>>> > Ipv4Header and be able to pass back a modified IP header that will >>>>>> need to >>>>>> > go forward with the packet, and if the Netfilter client code expects >>>>>> to >>>>>> > mangle everything within a packed packet structure, that would mean >>>>>> doing >>>>>> > AddHeader(), mangle, RemoveHeader() which seems not so great. >>>>>> >>>>>> >>>>>> Correct. Maybe it is better for the Netfilter code to receive and >>>>>> return >>>>>> back also the IP header. It's probably more efficient too. This is >>>>>> basically what the Ipv4routingProtocol (at least the way I had >>>>>> implemented >>>>>> it initially, no idea if it has changed) did too: it received a packet >>>>>> without IP header plus the IP header, and it returned back a possibly >>>>>> modified packet plus possibly modified IP header. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -- >>>>>> Gustavo J. A. M. Carneiro >>>>>> INESC Porto, Telecommunications and Multimedia Unit >>>>>> "The universe is always one step beyond logic." -- Frank Herbert >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Gustavo J. A. M. Carneiro >>>> INESC Porto, Telecommunications and Multimedia Unit >>>> "The universe is always one step beyond logic." -- Frank Herbert >>>> >>> >>> >>> >>> -- >>> Gustavo J. A. M. Carneiro >>> INESC Porto, Telecommunications and Multimedia Unit >>> "The universe is always one step beyond logic." -- Frank Herbert >>> >> >> > > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From craigdo at ee.washington.edu Fri Sep 18 15:31:36 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 18 Sep 2009 15:31:36 -0700 Subject: [Ns-developers] Ns-3.6 Release and ns-3-dev Status In-Reply-To: <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain> <5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> Message-ID: <000401ca38af$c8b24900$a3d75f80@ee.washington.edu> Hi All, This email is to remind everyone that the open phase of ns-3.6 has now ended. All of the new features that are going to be in ns-3.6 are now merged into ns-3-dev. If you have an addition you want to get into ns-3-dev, you will now have to wait until the ns-3.7 open phase which is scheduled to start on October 14, 2009. The remaining milestones for ns-3.6 are: September 30 -- Maintenance phase ends; September 30 -- Code freeze phase begins; October 1 -- ns-3.6-RC1; October 5 -- ns-3.6-RC2; October 8 -- ns-3.6-RC3; October 12 -- ns-3.6-RC4; October 14 -- ns-3.6 posted; October 14 -- Code freeze phase ends; October 14 -- ns-3.7 Open phase begins. According to the schedule (and in reality), we are now in the maintenance phase of the release. The fact that we are in maintenance phase means that checkins are now limited to fixing bugs that have been logged in bugzilla. Any checkins should have mercurial commit messages that reference a specific bug or bugs. The time to make unnecessary or just nice-to-have changes has passed. We are trying to enter a period of relative stability before the release so let's be very careful about breaking the build, unit tests, regression tests, etc. Now would be a good time to start beating on the new features we have just merged, in order to exercise them as much as possible before the release looms (which will happen very quickly now). They are listed here: http://www.nsnam.org/wiki/index.php/Ns-3.6 The next phase, code freeze, will limit changes to only bug fixes for bugs identified as priority one (P1), which means that they must be fixed before release. We are going to start being very restrictive about what can be done with ns-3-dev on October 1st. We will be reviewing the current bug list to identify the P1 bugs for this release in the next few days. Regards, -- Craig From craigdo at ee.washington.edu Fri Sep 18 17:08:57 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 18 Sep 2009 17:08:57 -0700 Subject: [Ns-developers] Ns-3.7 Release Schedule (yes,that is ns-3.7) In-Reply-To: <000401ca38af$c8b24900$a3d75f80@ee.washington.edu> References: <1252435777.2647.4.camel@localhost.localdomain><5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO> <000401ca38af$c8b24900$a3d75f80@ee.washington.edu> Message-ID: Hi All, In an attempt to remind everyone of how fast these ns-3 releases are actually coming, and to try and get ahead of the game a little, I have created an ns-3.7 release page for your viewing pleasure: http://www.nsnam.org/wiki/index.php/Ns-3.7 Release pages are linked from the main wiki page, BTW. The schedule is tentative at this time, but here it is: 1.October 14 -- ns-3.6 posted; 2.October 14 -- ns-3.7 Open phase begins; 3.November 18 -- Recommended cutoff for new feature submission; 4.November 25 -- Deadline for new feature submissions that require design review; 5.December 2 -- Approved new feature ready-for-merge deadline; 6.December 9 -- Late merge period begins (Merge Week Begins); 7.December 16 -- Late merge period ends; 8.December 16 -- Open phase ends; 9.December 16 -- Maintenance phase begins;> 10.January 6 -- Maintenance phase ends; 11.January 6 -- Code freeze phase begins; 12.January 6 -- ns-3.7-RC1; 13.January 8 -- ns-3.7-RC2; 14.January 12 -- ns-3.7-RC3; 15.January 15 -- ns-3.7-RC4; 16.January 20 -- ns-3.7 posted; 17.January 20 -- Code freeze phase ends; 18.January 20 -- ns-3.8 Open phase begins. Notice that the open phase for ns-3.7 starts in a little less than a month and the recommended date for having a new feature ready to go in is a mere two months from today. Also remember that we have many holidays coming up that will eat into this schedule. I have pushed the schedule out slightly to accommodate this. If you would like to get your submission listed for ns-3.7, just email me and I will begin actively maintaining the release page. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Fri Sep 18 18:26:42 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 18 Sep 2009 18:26:42 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200909190126.n8J1QgGC008660@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/108 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From craigdo at ee.washington.edu Fri Sep 18 19:50:12 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 18 Sep 2009 19:50:12 -0700 Subject: [Ns-developers] Ns-3.6 Tentative P1 Bug List In-Reply-To: <6223EC9131374B30888FAD22F7814389@CRAIGVAIO> References: <1252435777.2647.4.camel@localhost.localdomain><5FFEAC6994FC4644B9FB53478B7B80BC@CRAIGVAIO><000401ca38af$c8b24900$a3d75f80@ee.washington.edu> <6223EC9131374B30888FAD22F7814389@CRAIGVAIO> Message-ID: Hi All, Now that we are in the maintenance phase of ns-3.6 it is a good idea to figure out what we are going to fix. We have put together a tentative list of P1 bugs that, by definition, must be fixed for this release. You can find them here: http://www.nsnam.org/wiki/index.php/Ns-3.6 These have all been bumped up to priority one if they were not already. If you have another bug you'd like to see put on this list, or you don't agree that one should be there, please let me know. We are going to start assigning these bugs to people on Monday. If you're a hearty soul and would like to volunteer instead of being volunteered, I will very happily let you give it a shot. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Fri Sep 18 23:13:08 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 18 Sep 2009 23:13:08 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.2 Message-ID: <200909190613.n8J6D8H8008918@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/104 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From tomh at tomh.org Sun Sep 20 22:17:24 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 20 Sep 2009 22:17:24 -0700 Subject: [Ns-developers] ns-3.5.1 release? In-Reply-To: <1253172837.24392.93.camel@diese.inria.fr> References: <4AADC143.8060305@tomh.org> <1253002048.14583.10.camel@diese.inria.fr> <1253172837.24392.93.camel@diese.inria.fr> Message-ID: <4AB70C64.6050706@tomh.org> Mathieu Lacage wrote: > The code is now there: > http://code.nsnam.org/mathieu/ns-3.5.1 > > I am waiting for sam and florian to do an nsc 0.6 release and, once this > is done, I will attempt 3.5.1. This works for me (tested on one Linux machine). Any chance of including the patch for bug 643 (both in ns-3-dev and ns-3.5.1)? Thanks, Tom From dnlove at gmail.com Sun Sep 20 23:50:10 2009 From: dnlove at gmail.com (Duy Nguyen) Date: Sun, 20 Sep 2009 23:50:10 -0700 Subject: [Ns-developers] multiple simultaneous flows with olsr(seems buggy) and aodv Message-ID: <70f6a1ed0909202350v31ad1368t9bb2af202e79e785@mail.gmail.com> I am not sure if this is a bug in olsr but I could not get the multiple flows going on with olsr selected as the choice routing. I notice that there's usually no more than one flow happening even if i force them(I verify it by going to pcap files). I have tested the same script with aodv and it does not seem to have this problem. My testscript is attached here. The attached test scripts set up the scenarios as follow: 4x4 grid for a total of 16 nodes n13 n14 n15 n16 n09 n10 n11 n12 n05 n06 n07 n08 n01 n02 n03 n04 the distance between each node is 150 meters source and destination pairs are n01 --> n02 n03 --> n04 .... and so on up to n15 --> n16 For a total of 8 flows and they all begin at the same time. If anyone has gotten olsr to work with many simultaneous flow in multi-hop ad-hoc environment, could you share the scripts? I cced ns-3 users, hope developers there can also help out. Duy -------------- next part -------------- A non-text attachment was scrubbed... Name: many-flows-test.cc Type: text/x-c++src Size: 7279 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090920/9e22ab48/many-flows-test.bin From gjcarneiro at gmail.com Mon Sep 21 03:58:49 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 21 Sep 2009 11:58:49 +0100 Subject: [Ns-developers] [Ns-commits] Output of run-tests script: failure In-Reply-To: <200909211055.n8LAtA6w010511@ns-regression.ee.washington.edu> References: <200909211055.n8LAtA6w010511@ns-regression.ee.washington.edu> Message-ID: I opened a bug report for this build failure. It is not an easy fix, far from it :( http://www.nsnam.org/bugzilla/show_bug.cgi?id=685 2009/9/21 > Mon Sep 21 02:51:12 PDT 2009 download.py success Regression testing for > machine: ns-regression Linux 2.6.24-19-server x86_64 g++ (GCC) 4.2.4 (Ubuntu > 4.2.4-1ubuntu3) ----------------------------- SUCCESS: waf -d debug > configure; ./waf --valgrind --regression passed on ns-3-dev SUCCESS: waf -d > optimized configure; ./waf --valgrind --regression passed on ns-3-dev > Regression testing for machine: ns-regression Linux 2.6.24-19-server x86_64 > g++-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu5) ----------------------------- > SUCCESS: waf -d debug configure; ./waf --regression passed on ns-3-dev > Regression testing for machine: ns-ubuntu-intrepid Linux 2.6.27-2-generic > i686 g++ (Ubuntu 4.3.2-1ubuntu11) 4.3.2 ----------------------------- > FAILURE: waf -d debug configure; building failed on ns-ubuntu-intrepid > Configure stderr: Checking for program g++ : ok /usr/bin/g++ Checking for > program cpp : ok /usr/bin/cpp Checking for program ar : ok /usr/bin/ar > Checking for program ranlib : ok /usr/bin/ranlib Checking for g++ : ok > Checking for program pkg-config : ok /usr/bin/pkg-config Checking for > regression traces location : ok ../ns-3-dev-ref-traces (given) Checking for > -Wno-error=deprecated-declarations support : yes Checking for > -Wl,--soname=foo support : yes Checking for header stdlib.h : ok Checking > for header signal.h : ok Checking for header pthread.h : ok Checking for > high precision time implementation : 128-bit integer Checking for header > stdint.h : ok Checking for header inttypes.h : ok Checking for header > sys/inttypes.h : not found Checking for library rt : ok Checking for header > netpacket/packet.h : ok Checking for header linux/if_tun.h : ok Package > gtk+-2.0 was not found in the pkg-config search path. Perhaps you should add > the directory containing `gtk+-2.0.pc' to the PKG_CONFIG_PATH environment > variable No package 'gtk+-2.0' found Checking for pkg-config flags for > GTK_CONFIG_STORE : not found Package libxml-2.0 was not found in the > pkg-config search path. Perhaps you should add the directory containing > `libxml-2.0.pc' to the PKG_CONFIG_PATH environment variable No package > 'libxml-2.0' found Checking for pkg-config flags for LIBXML2 : not found > Checking for library sqlite3 : not found Checking for NSC location : not > found Checking for program python : ok /usr/bin/python Checking for Python > version >= 2.3 : ok 2.5.2 Checking for library python2.5 : ok Checking for > program python2.5-config : ok /usr/bin/python2.5-config Checking for header > Python.h : ok Checking for -fvisibility=hidden support : yes Checking for > pybindgen location : ok ../pybindgen (given) Checking for Python module > pybindgen : ok Checking for pybindgen version : ok 0.12.0.700 Checking for > Python module pygccxml : not found Checking for program sudo : ok > /usr/bin/sudo Checking for program hg : ok /usr/bin/hg Checking for program > valgrind : not found Package gsl was not found in the pkg-config search > path. Perhaps you should add the directory containing `gsl.pc' to the > PKG_CONFIG_PATH environment variable No package 'gsl' found Checking for > pkg-config flags for GSL : not found 'configure' finished successfully > (3.494s) Build stderr: Waf: Entering directory > `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build' [ 1/905] ns3header: > src/core/system-wall-clock-ms.h -> build/debug/ns3/system-wall-clock-ms.h [ > 2/905] ns3header: src/core/empty.h -> build/debug/ns3/empty.h [ 3/905] > ns3header: src/core/callback.h -> build/debug/ns3/callback.h [ 4/905] > ns3header: src/core/object-base.h -> build/debug/ns3/object-base.h [ 5/905] > ns3header: src/core/ref-count-base.h -> build/debug/ns3/ref-count-base.h [ > 6/905] ns3header: src/core/type-id.h -> build/debug/ns3/type-id.h [ 7/905] > ns3header: src/core/attribute-list.h -> build/debug/ns3/attribute-list.h [ > 8/905] ns3header: src/core/ptr.h -> build/debug/ns3/ptr.h [ 9/905] > ns3header: src/core/object.h -> build/debug/ns3/object.h [ 10/905] > ns3header: src/core/log.h -> build/debug/ns3/log.h [ 11/905] ns3header: > src/core/assert.h -> build/debug/ns3/assert.h [ 12/905] ns3header: > src/core/breakpoint.h -> build/debug/ns3/breakpoint.h [ 13/905] ns3header: > src/core/fatal-error.h -> build/debug/ns3/fatal-error.h [ 14/905] ns3header: > src/core/test.h -> build/debug/ns3/test.h [ 15/905] ns3header: > src/core/random-variable.h -> build/debug/ns3/random-variable.h [ 16/905] > ns3header: src/core/rng-stream.h -> build/debug/ns3/rng-stream.h [ 17/905] > ns3header: src/core/command-line.h -> build/debug/ns3/command-line.h [ > 18/905] ns3header: src/core/type-name.h -> build/debug/ns3/type-name.h [ > 19/905] ns3header: src/core/type-traits.h -> build/debug/ns3/type-traits.h [ > 20/905] ns3header: src/core/int-to-type.h -> build/debug/ns3/int-to-type.h [ > 21/905] ns3header: src/core/attribute.h -> build/debug/ns3/attribute.h [ > 22/905] ns3header: src/core/attribute-accessor-helper.h -> > build/debug/ns3/attribute-accessor-helper.h [ 23/905] ns3header: > src/core/boolean.h -> build/debug/ns3/boolean.h [ 24/905] ns3header: > src/core/integer.h -> build/debug/ns3/integer.h [ 25/905] ns3header: > src/core/uinteger.h -> build/debug/ns3/uinteger.h [ 26/905] ns3header: > src/core/double.h -> build/debug/ns3/double.h [ 27/905] ns3header: > src/core/enum.h -> build/debug/ns3/enum.h [ 28/905] ns3header: > src/core/string.h -> build/debug/ns3/string.h [ 29/905] ns3header: > src/core/pointer.h -> build/debug/ns3/pointer.h [ 30/905] ns3header: > src/core/object-factory.h -> build/debug/ns3/object-factory.h [ 31/905] > ns3header: src/core/attribute-helper.h -> build/debug/ns3/attribute-helper.h > [ 32/905] ns3header: src/core/global-value.h -> > build/debug/ns3/global-value.h [ 33/905] ns3header: > src/core/traced-callback.h -> build/debug/ns3/traced-callback.h [ 34/905] > ns3header: src/core/traced-value.h -> build/debug/ns3/traced-value.h [ > 35/905] ns3header: src/core/trace-source-accessor.h -> > build/debug/ns3/trace-source-accessor.h [ 36/905] ns3header: > src/core/config.h -> build/debug/ns3/config.h [ 37/905] ns3header: > src/core/object-vector.h -> build/debug/ns3/object-vector.h [ 38/905] > ns3header: src/core/deprecated.h -> build/debug/ns3/deprecated.h [ 39/905] > ns3header: src/core/abort.h -> build/debug/ns3/abort.h [ 40/905] ns3header: > src/core/names.h -> build/debug/ns3/names.h [ 41/905] ns3header: > src/core/vector.h -> build/debug/ns3/vector.h [ 42/905] ns3header: > src/core/system-mutex.h -> build/debug/ns3/system-mutex.h [ 43/905] > ns3header: src/core/system-thread.h -> build/debug/ns3/system-thread.h [ > 44/905] ns3header: src/core/system-condition.h -> > build/debug/ns3/system-condition.h [ 45/905] ns3header: src/common/buffer.h > -> build/debug/ns3/buffer.h [ 46/905] ns3header: src/common/chunk.h -> > build/debug/ns3/chunk.h [ 47/905] ns3header: src/common/header.h -> > build/debug/ns3/header.h [ 48/905] ns3header: src/common/trailer.h -> > build/debug/ns3/trailer.h [ 49/905] ns3header: src/common/packet.h -> > build/debug/ns3/packet.h [ 50/905] ns3header: src/common/packet-metadata.h > -> build/debug/ns3/packet-metadata.h [ 51/905] ns3header: > src/common/pcap-writer.h -> build/debug/ns3/pcap-writer.h [ 52/905] > ns3header: src/common/data-rate.h -> build/debug/ns3/data-rate.h [ 53/905] > ns3header: src/common/error-model.h -> build/debug/ns3/error-model.h [ > 54/905] ns3header: src/common/tag.h -> build/debug/ns3/tag.h [ 55/905] > ns3header: src/common/byte-tag-list.h -> build/debug/ns3/byte-tag-list.h [ > 56/905] ns3header: src/common/tag-buffer.h -> build/debug/ns3/tag-buffer.h [ > 57/905] ns3header: src/common/packet-tag-list.h -> > build/debug/ns3/packet-tag-list.h [ 58/905] ns3header: > src/common/nix-vector.h -> build/debug/ns3/nix-vector.h [ 59/905] ns3header: > src/common/ascii-writer.h -> build/debug/ns3/ascii-writer.h [ 60/905] > ns3header: src/common/sgi-hashmap.h -> build/debug/ns3/sgi-hashmap.h [ > 61/905] ns3header: src/common/pcap-file.h -> build/debug/ns3/pcap-file.h [ > 62/905] ns3header: src/simulator/high-precision.h -> > build/debug/ns3/high-precision.h [ 63/905] ns3header: src/simulator/nstime.h > -> build/debug/ns3/nstime.h [ 64/905] ns3header: src/simulator/event-id.h -> > build/debug/ns3/event-id.h [ 65/905] ns3header: src/simulator/event-impl.h > -> build/debug/ns3/event-impl.h [ 66/905] ns3header: > src/simulator/simulator.h -> build/debug/ns3/simulator.h [ 67/905] > ns3header: src/simulator/simulator-impl.h -> > build/debug/ns3/simulator-impl.h [ 68/905] ns3header: > src/simulator/default-simulator-impl.h -> > build/debug/ns3/default-simulator-impl.h [ 69/905] ns3header: > src/simulator/scheduler.h -> build/debug/ns3/scheduler.h [ 70/905] > ns3header: src/simulator/list-scheduler.h -> > build/debug/ns3/list-scheduler.h [ 71/905] ns3header: > src/simulator/map-scheduler.h -> build/debug/ns3/map-scheduler.h [ 72/905] > ns3header: src/simulator/heap-scheduler.h -> > build/debug/ns3/heap-scheduler.h [ 73/905] ns3header: > src/simulator/calendar-scheduler.h -> build/debug/ns3/calendar-scheduler.h [ > 74/905] ns3header: src/simulator/ns2-calendar-scheduler.h -> > build/debug/ns3/ns2-calendar-scheduler.h [ 75/905] ns3header: > src/simulator/simulation-singleton.h -> > build/debug/ns3/simulation-singleton.h [ 76/905] ns3header: > src/simulator/timer.h -> build/debug/ns3/timer.h [ 77/905] ns3header: > src/simulator/timer-impl.h -> build/debug/ns3/timer-impl.h [ 78/905] > ns3header: src/simulator/watchdog.h -> build/debug/ns3/watchdog.h [ 79/905] > ns3header: src/simulator/synchronizer.h -> build/debug/ns3/synchronizer.h [ > 80/905] ns3header: src/simulator/make-event.h -> > build/debug/ns3/make-event.h [ 81/905] ns3header: > src/simulator/high-precision-128.h -> build/debug/ns3/high-precision-128.h [ > 82/905] ns3header: src/simulator/cairo-wideint-private.h -> > build/debug/ns3/cairo-wideint-private.h [ 83/905] ns3header: > src/simulator/realtime-simulator-impl.h -> > build/debug/ns3/realtime-simulator-impl.h [ 84/905] ns3header: > src/simulator/wall-clock-synchronizer.h -> > build/debug/ns3/wall-clock-synchronizer.h [ 85/905] ns3header: > src/contrib/event-garbage-collector.h -> > build/debug/ns3/event-garbage-collector.h [ 86/905] ns3header: > src/contrib/gnuplot.h -> build/debug/ns3/gnuplot.h [ 87/905] ns3header: > src/contrib/delay-jitter-estimation.h -> > build/debug/ns3/delay-jitter-estimation.h [ 88/905] ns3header: > src/contrib/file-config.h -> build/debug/ns3/file-config.h [ 89/905] > ns3header: src/contrib/config-store.h -> build/debug/ns3/config-store.h [ > 90/905] ns3header: src/contrib/flow-id-tag.h -> > build/debug/ns3/flow-id-tag.h [ 91/905] ns3header: src/node/address.h -> > build/debug/ns3/address.h [ 92/905] ns3header: src/node/mac48-address.h -> > build/debug/ns3/mac48-address.h [ 93/905] ns3header: > src/node/mac64-address.h -> build/debug/ns3/mac64-address.h [ 94/905] > ns3header: src/node/inet-socket-address.h -> > build/debug/ns3/inet-socket-address.h [ 95/905] ns3header: > src/node/packet-socket-address.h -> build/debug/ns3/packet-socket-address.h > [ 96/905] ns3header: src/node/node.h -> build/debug/ns3/node.h [ 97/905] > ns3header: src/node/ipv4-address.h -> build/debug/ns3/ipv4-address.h [ > 98/905] ns3header: src/node/ipv4-interface-address.h -> > build/debug/ns3/ipv4-interface-address.h [ 99/905] ns3header: > src/node/ipv4-address-generator.h -> > build/debug/ns3/ipv4-address-generator.h [100/905] ns3header: > src/node/ipv4-header.h -> build/debug/ns3/ipv4-header.h [101/905] ns3header: > src/node/net-device.h -> build/debug/ns3/net-device.h [102/905] ns3header: > src/node/address-utils.h -> build/debug/ns3/address-utils.h [103/905] > ns3header: src/node/ipv4-route.h -> build/debug/ns3/ipv4-route.h [104/905] > ns3header: src/node/ipv4-routing-protocol.h -> > build/debug/ns3/ipv4-routing-protocol.h [105/905] ns3header: > src/node/queue.h -> build/debug/ns3/queue.h [106/905] ns3header: > src/node/drop-tail-queue.h -> build/debug/ns3/drop-tail-queue.h [107/905] > ns3header: src/node/llc-snap-header.h -> build/debug/ns3/llc-snap-header.h > [108/905] ns3header: src/node/ethernet-header.h -> > build/debug/ns3/ethernet-header.h [109/905] ns3header: > src/node/ethernet-trailer.h -> build/debug/ns3/ethernet-trailer.h [110/905] > ns3header: src/node/channel.h -> build/debug/ns3/channel.h [111/905] > ns3header: src/node/node-list.h -> build/debug/ns3/node-list.h [112/905] > ns3header: src/node/socket.h -> build/debug/ns3/socket.h [113/905] > ns3header: src/node/socket-factory.h -> build/debug/ns3/socket-factory.h > [114/905] ns3header: src/node/packet-socket-factory.h -> > build/debug/ns3/packet-socket-factory.h [115/905] ns3header: > src/node/udp-socket.h -> build/debug/ns3/udp-socket.h [116/905] ns3header: > src/node/udp-socket-factory.h -> build/debug/ns3/udp-socket-factory.h > [117/905] ns3header: src/node/tcp-socket.h -> build/debug/ns3/tcp-socket.h > [118/905] ns3header: src/node/tcp-socket-factory.h -> > build/debug/ns3/tcp-socket-factory.h [119/905] ns3header: src/node/ipv4.h -> > build/debug/ns3/ipv4.h [120/905] ns3header: > src/node/ipv4-raw-socket-factory.h -> > build/debug/ns3/ipv4-raw-socket-factory.h [121/905] ns3header: > src/node/application.h -> build/debug/ns3/application.h [122/905] ns3header: > src/node/simple-channel.h -> build/debug/ns3/simple-channel.h [123/905] > ns3header: src/node/simple-net-device.h -> > build/debug/ns3/simple-net-device.h [124/905] ns3header: > src/node/inet6-socket-address.h -> build/debug/ns3/inet6-socket-address.h > [125/905] ns3header: src/node/ipv6-address.h -> > build/debug/ns3/ipv6-address.h [126/905] ns3header: src/node/ipv6-header.h > -> build/debug/ns3/ipv6-header.h [127/905] ns3header: > src/node/ipv6-interface-address.h -> > build/debug/ns3/ipv6-interface-address.h [128/905] ns3header: > src/node/ipv6-route.h -> build/debug/ns3/ipv6-route.h [129/905] ns3header: > src/node/ipv6.h -> build/debug/ns3/ipv6.h [130/905] ns3header: > src/node/ipv6-raw-socket-factory.h -> > build/debug/ns3/ipv6-raw-socket-factory.h [131/905] ns3header: > src/node/ipv6-routing-protocol.h -> build/debug/ns3/ipv6-routing-protocol.h > [132/905] ns3header: src/node/packetbb.h -> build/debug/ns3/packetbb.h > [133/905] ns3header: src/internet-stack/udp-header.h -> > build/debug/ns3/udp-header.h [134/905] ns3header: > src/internet-stack/tcp-header.h -> build/debug/ns3/tcp-header.h [135/905] > ns3header: src/internet-stack/sequence-number.h -> > build/debug/ns3/sequence-number.h [136/905] ns3header: > src/internet-stack/icmpv4.h -> build/debug/ns3/icmpv4.h [137/905] ns3header: > src/internet-stack/icmpv6-header.h -> build/debug/ns3/icmpv6-header.h > [138/905] ns3header: src/internet-stack/ipv4-l3-protocol.h -> > build/debug/ns3/ipv4-l3-protocol.h [139/905] ns3header: > src/internet-stack/ipv6-l3-protocol.h -> build/debug/ns3/ipv6-l3-protocol.h > [140/905] ns3header: src/internet-stack/arp-l3-protocol.h -> > build/debug/ns3/arp-l3-protocol.h [141/905] ns3header: > src/internet-stack/udp-l4-protocol.h -> build/debug/ns3/udp-l4-protocol.h > [142/905] ns3header: src/internet-stack/tcp-l4-protocol.h -> > build/debug/ns3/tcp-l4-protocol.h [143/905] ns3header: > src/internet-stack/icmpv4-l4-protocol.h -> > build/debug/ns3/icmpv4-l4-protocol.h [144/905] ns3header: > src/internet-stack/ipv4-l4-protocol.h -> build/debug/ns3/ipv4-l4-protocol.h > [145/905] ns3header: src/internet-stack/arp-cache.h -> > build/debug/ns3/arp-cache.h [146/905] ns3header: > src/internet-stack/icmpv6-l4-protocol.h -> > build/debug/ns3/icmpv6-l4-protocol.h [147/905] ns3header: > src/internet-stack/ipv6-l4-protocol.h -> build/debug/ns3/ipv6-l4-protocol.h > [148/905] ns3header: src/internet-stack/ndisc-cache.h -> > build/debug/ns3/ndisc-cache.h [149/905] ns3header: > src/devices/point-to-point/point-to-point-net-device.h -> > build/debug/ns3/point-to-point-net-device.h [150/905] ns3header: > src/devices/point-to-point/point-to-point-channel.h -> > build/debug/ns3/point-to-point-channel.h [151/905] ns3header: > src/devices/point-to-point/ppp-header.h -> build/debug/ns3/ppp-header.h > [152/905] ns3header: src/devices/csma/backoff.h -> build/debug/ns3/backoff.h > [153/905] ns3header: src/devices/csma/csma-net-device.h -> > build/debug/ns3/csma-net-device.h [154/905] ns3header: > src/devices/csma/csma-channel.h -> build/debug/ns3/csma-channel.h [155/905] > ns3header: src/devices/emu/emu.h -> build/debug/ns3/emu.h [156/905] > ns3header: src/devices/emu/emu-net-device.h -> > build/debug/ns3/emu-net-device.h [157/905] ns3header: > src/devices/bridge/bridge-net-device.h -> > build/debug/ns3/bridge-net-device.h [158/905] ns3header: > src/devices/bridge/bridge-channel.h -> build/debug/ns3/bridge-channel.h > [159/905] ns3header: src/devices/tap-bridge/tap.h -> build/debug/ns3/tap.h > [160/905] ns3header: src/devices/tap-bridge/tap-bridge.h -> > build/debug/ns3/tap-bridge.h [161/905] ns3header: > src/devices/virtual-net-device/virtual-net-device.h -> > build/debug/ns3/virtual-net-device.h [162/905] ns3header: > src/applications/onoff/onoff-application.h -> > build/debug/ns3/onoff-application.h [163/905] ns3header: > src/applications/packet-sink/packet-sink.h -> build/debug/ns3/packet-sink.h > [164/905] ns3header: src/applications/udp-echo/udp-echo-client.h -> > build/debug/ns3/udp-echo-client.h [165/905] ns3header: > src/applications/udp-echo/udp-echo-server.h -> > build/debug/ns3/udp-echo-server.h [166/905] ns3header: > src/routing/nix-vector-routing/ipv4-nix-vector-routing.h -> > build/debug/ns3/ipv4-nix-vector-routing.h [167/905] ns3header: > src/routing/olsr/olsr-routing-protocol.h -> > build/debug/ns3/olsr-routing-protocol.h [168/905] ns3header: > src/routing/olsr/olsr-header.h -> build/debug/ns3/olsr-header.h [169/905] > ns3header: src/routing/olsr/olsr-state.h -> build/debug/ns3/olsr-state.h > [170/905] ns3header: src/routing/olsr/olsr-repositories.h -> > build/debug/ns3/olsr-repositories.h [171/905] ns3header: > src/routing/global-routing/global-router-interface.h -> > build/debug/ns3/global-router-interface.h [172/905] ns3header: > src/routing/global-routing/global-route-manager.h -> > build/debug/ns3/global-route-manager.h [173/905] ns3header: > src/routing/global-routing/ipv4-global-routing.h -> > build/debug/ns3/ipv4-global-routing.h [174/905] ns3header: > src/routing/static-routing/ipv4-static-routing.h -> > build/debug/ns3/ipv4-static-routing.h [175/905] ns3header: > src/routing/static-routing/ipv4-routing-table-entry.h -> > build/debug/ns3/ipv4-routing-table-entry.h [176/905] ns3header: > src/routing/static-routing/ipv6-static-routing.h -> > build/debug/ns3/ipv6-static-routing.h [177/905] ns3header: > src/routing/static-routing/ipv6-routing-table-entry.h -> > build/debug/ns3/ipv6-routing-table-entry.h [178/905] ns3header: > src/routing/list-routing/ipv4-list-routing.h -> > build/debug/ns3/ipv4-list-routing.h [179/905] ns3header: > src/routing/list-routing/ipv6-list-routing.h -> > build/debug/ns3/ipv6-list-routing.h [180/905] ns3header: > src/mobility/hierarchical-mobility-model.h -> > build/debug/ns3/hierarchical-mobility-model.h [181/905] ns3header: > src/mobility/mobility-model.h -> build/debug/ns3/mobility-model.h [182/905] > ns3header: src/mobility/position-allocator.h -> > build/debug/ns3/position-allocator.h [183/905] ns3header: > src/mobility/rectangle.h -> build/debug/ns3/rectangle.h [184/905] ns3header: > src/mobility/constant-position-mobility-model.h -> > build/debug/ns3/constant-position-mobility-model.h [185/905] ns3header: > src/mobility/constant-velocity-helper.h -> > build/debug/ns3/constant-velocity-helper.h [186/905] ns3header: > src/mobility/constant-velocity-mobility-model.h -> > build/debug/ns3/constant-velocity-mobility-model.h [187/905] ns3header: > src/mobility/random-waypoint-mobility-model.h -> > build/debug/ns3/random-waypoint-mobility-model.h [188/905] ns3header: > src/mobility/random-walk-2d-mobility-model.h -> > build/debug/ns3/random-walk-2d-mobility-model.h [189/905] ns3header: > src/mobility/random-direction-2d-mobility-model.h -> > build/debug/ns3/random-direction-2d-mobility-model.h [190/905] ns3header: > src/mobility/constant-acceleration-mobility-model.h -> > build/debug/ns3/constant-acceleration-mobility-model.h [191/905] ns3header: > src/devices/wifi/propagation-delay-model.h -> > build/debug/ns3/propagation-delay-model.h [192/905] ns3header: > src/devices/wifi/propagation-loss-model.h -> > build/debug/ns3/propagation-loss-model.h [193/905] ns3header: > src/devices/wifi/jakes-propagation-loss-model.h -> > build/debug/ns3/jakes-propagation-loss-model.h [194/905] ns3header: > src/devices/wifi/wifi-net-device.h -> build/debug/ns3/wifi-net-device.h > [195/905] ns3header: src/devices/wifi/wifi-channel.h -> > build/debug/ns3/wifi-channel.h [196/905] ns3header: > src/devices/wifi/wifi-mode.h -> build/debug/ns3/wifi-mode.h [197/905] > ns3header: src/devices/wifi/ssid.h -> build/debug/ns3/ssid.h [198/905] > ns3header: src/devices/wifi/wifi-preamble.h -> > build/debug/ns3/wifi-preamble.h [199/905] ns3header: > src/devices/wifi/wifi-phy-standard.h -> build/debug/ns3/wifi-phy-standard.h > [200/905] ns3header: src/devices/wifi/yans-wifi-phy.h -> > build/debug/ns3/yans-wifi-phy.h [201/905] ns3header: > src/devices/wifi/yans-wifi-channel.h -> build/debug/ns3/yans-wifi-channel.h > [202/905] ns3header: src/devices/wifi/wifi-phy.h -> > build/debug/ns3/wifi-phy.h [203/905] ns3header: > src/devices/wifi/interference-helper.h -> > build/debug/ns3/interference-helper.h [204/905] ns3header: > src/devices/wifi/wifi-remote-station-manager.h -> > build/debug/ns3/wifi-remote-station-manager.h [205/905] ns3header: > src/devices/wifi/arf-wifi-manager.h -> build/debug/ns3/arf-wifi-manager.h > [206/905] ns3header: src/devices/wifi/aarf-wifi-manager.h -> > build/debug/ns3/aarf-wifi-manager.h [207/905] ns3header: > src/devices/wifi/constant-rate-wifi-manager.h -> > build/debug/ns3/constant-rate-wifi-manager.h [208/905] ns3header: > src/devices/wifi/ideal-wifi-manager.h -> > build/debug/ns3/ideal-wifi-manager.h [209/905] ns3header: > src/devices/wifi/amrr-wifi-manager.h -> build/debug/ns3/amrr-wifi-manager.h > [210/905] ns3header: src/devices/wifi/onoe-wifi-manager.h -> > build/debug/ns3/onoe-wifi-manager.h [211/905] ns3header: > src/devices/wifi/rraa-wifi-manager.h -> build/debug/ns3/rraa-wifi-manager.h > [212/905] ns3header: src/devices/wifi/wifi-mac.h -> > build/debug/ns3/wifi-mac.h [213/905] ns3header: > src/devices/wifi/adhoc-wifi-mac.h -> build/debug/ns3/adhoc-wifi-mac.h > [214/905] ns3header: src/devices/wifi/nqsta-wifi-mac.h -> > build/debug/ns3/nqsta-wifi-mac.h [215/905] ns3header: > src/devices/wifi/nqap-wifi-mac.h -> build/debug/ns3/nqap-wifi-mac.h > [216/905] ns3header: src/devices/wifi/wifi-phy.h -> > build/debug/ns3/wifi-phy.h [217/905] ns3header: > src/devices/wifi/supported-rates.h -> build/debug/ns3/supported-rates.h > [218/905] ns3header: src/devices/wifi/error-rate-model.h -> > build/debug/ns3/error-rate-model.h [219/905] ns3header: > src/devices/wifi/yans-error-rate-model.h -> > build/debug/ns3/yans-error-rate-model.h [220/905] ns3header: > src/devices/wifi/dca-txop.h -> build/debug/ns3/dca-txop.h [221/905] > ns3header: src/devices/wifi/wifi-mac-header.h -> > build/debug/ns3/wifi-mac-header.h [222/905] ns3header: > src/devices/wifi/qadhoc-wifi-mac.h -> build/debug/ns3/qadhoc-wifi-mac.h > [223/905] ns3header: src/devices/wifi/qap-wifi-mac.h -> > build/debug/ns3/qap-wifi-mac.h [224/905] ns3header: > src/devices/wifi/qsta-wifi-mac.h -> build/debug/ns3/qsta-wifi-mac.h > [225/905] ns3header: src/devices/wifi/qos-utils.h -> > build/debug/ns3/qos-utils.h [226/905] ns3header: > src/devices/wifi/edca-txop-n.h -> build/debug/ns3/edca-txop-n.h [227/905] > ns3header: src/devices/wifi/msdu-aggregator.h -> > build/debug/ns3/msdu-aggregator.h [228/905] ns3header: > src/devices/wifi/amsdu-subframe-header.h -> > build/debug/ns3/amsdu-subframe-header.h [229/905] ns3header: > src/devices/wifi/qos-tag.h -> build/debug/ns3/qos-tag.h [230/905] ns3header: > src/devices/wifi/mgt-headers.h -> build/debug/ns3/mgt-headers.h [231/905] > ns3header: src/devices/wifi/status-code.h -> build/debug/ns3/status-code.h > [232/905] ns3header: src/devices/wifi/capability-information.h -> > build/debug/ns3/capability-information.h [233/905] ns3header: > src/devices/wifi/dcf-manager.h -> build/debug/ns3/dcf-manager.h [234/905] > ns3header: src/devices/wifi/mac-rx-middle.h -> > build/debug/ns3/mac-rx-middle.h [235/905] ns3header: > src/devices/wifi/mac-low.h -> build/debug/ns3/mac-low.h [236/905] ns3header: > src/devices/wifi/minstrel-wifi-manager.h -> > build/debug/ns3/minstrel-wifi-manager.h [237/905] ns3header: > src/devices/wifi/dcf.h -> build/debug/ns3/dcf.h [238/905] ns3header: > src/helper/node-container.h -> build/debug/ns3/node-container.h [239/905] > ns3header: src/helper/net-device-container.h -> > build/debug/ns3/net-device-container.h [240/905] ns3header: > src/helper/wifi-helper.h -> build/debug/ns3/wifi-helper.h [241/905] > ns3header: src/helper/olsr-helper.h -> build/debug/ns3/olsr-helper.h > [242/905] ns3header: src/helper/point-to-point-helper.h -> > build/debug/ns3/point-to-point-helper.h [243/905] ns3header: > src/helper/csma-helper.h -> build/debug/ns3/csma-helper.h [244/905] > ns3header: src/helper/mobility-helper.h -> build/debug/ns3/mobility-helper.h > [245/905] ns3header: src/helper/ns2-mobility-helper.h -> > build/debug/ns3/ns2-mobility-helper.h [246/905] ns3header: > src/helper/ipv4-address-helper.h -> build/debug/ns3/ipv4-address-helper.h > [247/905] ns3header: src/helper/ipv4-static-routing-helper.h -> > build/debug/ns3/ipv4-static-routing-helper.h [248/905] ns3header: > src/helper/internet-stack-helper.h -> > build/debug/ns3/internet-stack-helper.h [249/905] ns3header: > src/helper/application-container.h -> > build/debug/ns3/application-container.h [250/905] ns3header: > src/helper/on-off-helper.h -> build/debug/ns3/on-off-helper.h [251/905] > ns3header: src/helper/packet-sink-helper.h -> > build/debug/ns3/packet-sink-helper.h [252/905] ns3header: > src/helper/packet-socket-helper.h -> build/debug/ns3/packet-socket-helper.h > [253/905] ns3header: src/helper/ipv4-interface-container.h -> > build/debug/ns3/ipv4-interface-container.h [254/905] ns3header: > src/helper/udp-echo-helper.h -> build/debug/ns3/udp-echo-helper.h [255/905] > ns3header: src/helper/bridge-helper.h -> build/debug/ns3/bridge-helper.h > [256/905] ns3header: src/helper/yans-wifi-helper.h -> > build/debug/ns3/yans-wifi-helper.h [257/905] ns3header: > src/helper/v4ping-helper.h -> build/debug/ns3/v4ping-helper.h [258/905] > ns3header: src/helper/nqos-wifi-mac-helper.h -> > build/debug/ns3/nqos-wifi-mac-helper.h [259/905] ns3header: > src/helper/qos-wifi-mac-helper.h -> build/debug/ns3/qos-wifi-mac-helper.h > [260/905] ns3header: src/helper/ipv4-nix-vector-helper.h -> > build/debug/ns3/ipv4-nix-vector-helper.h [261/905] ns3header: > src/helper/ipv4-global-routing-helper.h -> > build/debug/ns3/ipv4-global-routing-helper.h [262/905] ns3header: > src/helper/ipv4-list-routing-helper.h -> > build/debug/ns3/ipv4-list-routing-helper.h [263/905] ns3header: > src/helper/ipv4-routing-helper.h -> build/debug/ns3/ipv4-routing-helper.h > [264/905] ns3header: src/helper/mesh-helper.h -> > build/debug/ns3/mesh-helper.h [265/905] ns3header: > src/helper/mesh-stack-installer.h -> build/debug/ns3/mesh-stack-installer.h > [266/905] ns3header: src/helper/dot11s-installer.h -> > build/debug/ns3/dot11s-installer.h [267/905] ns3header: > src/helper/flame-installer.h -> build/debug/ns3/flame-installer.h [268/905] > ns3header: src/helper/athstats-helper.h -> build/debug/ns3/athstats-helper.h > [269/905] ns3header: src/helper/ipv6-address-helper.h -> > build/debug/ns3/ipv6-address-helper.h [270/905] ns3header: > src/helper/ipv6-interface-container.h -> > build/debug/ns3/ipv6-interface-container.h [271/905] ns3header: > src/helper/ipv6-static-routing-helper.h -> > build/debug/ns3/ipv6-static-routing-helper.h [272/905] ns3header: > src/helper/ipv6-list-routing-helper.h -> > build/debug/ns3/ipv6-list-routing-helper.h [273/905] ns3header: > src/helper/ipv6-routing-helper.h -> build/debug/ns3/ipv6-routing-helper.h > [274/905] ns3header: src/helper/ping6-helper.h -> > build/debug/ns3/ping6-helper.h [275/905] ns3header: > src/helper/flow-monitor-helper.h -> build/debug/ns3/flow-monitor-helper.h > [276/905] ns3header: src/helper/emu-helper.h -> build/debug/ns3/emu-helper.h > [277/905] ns3header: src/helper/tap-bridge-helper.h -> > build/debug/ns3/tap-bridge-helper.h [278/905] ns3header: > src/contrib/stats/data-calculator.h -> build/debug/ns3/data-calculator.h > [279/905] ns3header: src/contrib/stats/packet-data-calculators.h -> > build/debug/ns3/packet-data-calculators.h [280/905] ns3header: > src/contrib/stats/time-data-calculators.h -> > build/debug/ns3/time-data-calculators.h [281/905] ns3header: > src/contrib/stats/basic-data-calculators.h -> > build/debug/ns3/basic-data-calculators.h [282/905] ns3header: > src/contrib/stats/data-output-interface.h -> > build/debug/ns3/data-output-interface.h [283/905] ns3header: > src/contrib/stats/omnet-data-output.h -> build/debug/ns3/omnet-data-output.h > [284/905] ns3header: src/contrib/stats/data-collector.h -> > build/debug/ns3/data-collector.h [285/905] ns3header: > src/applications/v4ping/v4ping.h -> build/debug/ns3/v4ping.h [286/905] > ns3header: src/devices/mesh/wifi-information-element-vector.h -> > build/debug/ns3/wifi-information-element-vector.h [287/905] ns3header: > src/devices/mesh/mesh-point-device.h -> build/debug/ns3/mesh-point-device.h > [288/905] ns3header: src/devices/mesh/mesh-l2-routing-protocol.h -> > build/debug/ns3/mesh-l2-routing-protocol.h [289/905] ns3header: > src/devices/mesh/mesh-wifi-beacon.h -> build/debug/ns3/mesh-wifi-beacon.h > [290/905] ns3header: src/devices/mesh/mesh-wifi-interface-mac.h -> > build/debug/ns3/mesh-wifi-interface-mac.h [291/905] ns3header: > src/devices/mesh/mesh-wifi-interface-mac-plugin.h -> > build/debug/ns3/mesh-wifi-interface-mac-plugin.h [292/905] ns3header: > src/devices/mesh/dot11s/hwmp-protocol.h -> build/debug/ns3/hwmp-protocol.h > [293/905] ns3header: src/devices/mesh/dot11s/peer-management-protocol.h -> > build/debug/ns3/peer-management-protocol.h [294/905] ns3header: > src/devices/mesh/dot11s/ie-dot11s-beacon-timing.h -> > build/debug/ns3/ie-dot11s-beacon-timing.h [295/905] ns3header: > src/devices/mesh/dot11s/ie-dot11s-configuration.h -> > build/debug/ns3/ie-dot11s-configuration.h [296/905] ns3header: > src/devices/mesh/dot11s/ie-dot11s-peer-management.h -> > build/debug/ns3/ie-dot11s-peer-management.h [297/905] ns3header: > src/devices/mesh/dot11s/ie-dot11s-id.h -> build/debug/ns3/ie-dot11s-id.h > [298/905] ns3header: src/devices/mesh/dot11s/peer-link.h -> > build/debug/ns3/peer-link.h [299/905] ns3header: > src/devices/mesh/flame/flame-protocol.h -> build/debug/ns3/flame-protocol.h > [300/905] ns3header: src/applications/ping6/ping6.h -> > build/debug/ns3/ping6.h [301/905] ns3header: src/applications/radvd/radvd.h > -> build/debug/ns3/radvd.h [302/905] ns3header: > src/applications/radvd/radvd-interface.h -> > build/debug/ns3/radvd-interface.h [303/905] ns3header: > src/applications/radvd/radvd-prefix.h -> build/debug/ns3/radvd-prefix.h > [304/905] ns3header: src/test/ns3tcp/ns3tcp.h -> build/debug/ns3/ns3tcp.h > [305/905] ns3header: src/test/ns3wifi/ns3wifi.h -> build/debug/ns3/ns3wifi.h > [306/905] ns3header: src/contrib/flow-monitor/flow-monitor.h -> > build/debug/ns3/flow-monitor.h [307/905] ns3header: > src/contrib/flow-monitor/flow-probe.h -> build/debug/ns3/flow-probe.h > [308/905] ns3header: src/contrib/flow-monitor/flow-classifier.h -> > build/debug/ns3/flow-classifier.h [309/905] ns3header: > src/contrib/flow-monitor/ipv4-flow-classifier.h -> > build/debug/ns3/ipv4-flow-classifier.h [310/905] ns3header: > src/contrib/flow-monitor/ipv4-flow-probe.h -> > build/debug/ns3/ipv4-flow-probe.h [311/905] ns3header: > src/contrib/flow-monitor/histogram.h -> build/debug/ns3/histogram.h > [312/905] ns3header: src/contrib/net-anim/point-to-point-dumbbell-helper.h > -> build/debug/ns3/point-to-point-dumbbell-helper.h [313/905] ns3header: > src/contrib/net-anim/point-to-point-grid-helper.h -> > build/debug/ns3/point-to-point-grid-helper.h [314/905] ns3header: > src/contrib/net-anim/animation-interface.h -> > build/debug/ns3/animation-interface.h [315/905] ns3header: > src/contrib/net-anim/node-location.h -> build/debug/ns3/node-location.h > [316/905] command (${PYTHON}): bindings/python/ns3modulegen.py > bindings/python/ns3modulegen_generated.py > bindings/python/ns3modulegen_core_customizations.py > bindings/python/ns3_module_emu.py bindings/python/ns3_module_flow_monitor.py > bindings/python/ns3_module_packet_sink.py > bindings/python/ns3_module_onoff.py bindings/python/ns3_module_mobility.py > bindings/python/ns3_module_mesh.py bindings/python/ns3_module_node.py > bindings/python/ns3_module_common.py bindings/python/ns3_module_radvd.py > bindings/python/ns3_module_udp_echo.py > bindings/python/ns3_module_global_routing.py > bindings/python/ns3_module_stats.py bindings/python/ns3_module_ping6.py > bindings/python/ns3_module_static_routing.py > bindings/python/ns3_module_contrib.py bindings/python/ns3_module_flame.py > bindings/python/ns3_module_list_routing.py > bindings/python/ns3_module_v4ping.py bindings/python/ns3_module_bridge.py > bindings/python/ns3_module_helper.py bindings/python/ns3_module_simulator.py > bindings/python/ns3_module! _core.py bindings/python/ns3_module_csma.py > bindings/python/ns3_module_wifi.py > bindings/python/ns3_module_point_to_point.py > bindings/python/ns3_module_dot11s.py > bindings/python/ns3_module_internet_stack.py > bindings/python/ns3_module_virtual_net_device.py > bindings/python/ns3_module_tap_bridge.py bindings/python/ns3_module_olsr.py > -> build/debug/bindings/python/ns3module.cc > build/debug/bindings/python/ns3module.h > build/debug/bindings/python/ns3modulegen.log > build/debug/bindings/python/ns3_module_emu.cc > build/debug/bindings/python/ns3_module_flow_monitor.cc > build/debug/bindings/python/ns3_module_packet_sink.cc > build/debug/bindings/python/ns3_module_onoff.cc > build/debug/bindings/python/ns3_module_mobility.cc > build/debug/bindings/python/ns3_module_mesh.cc > build/debug/bindings/python/ns3_module_node.cc > build/debug/bindings/python/ns3_module_common.cc > build/debug/bindings/python/ns3_module_radvd.cc > build/debug/bindings/python/ns3_module_udp_echo.cc > build/debug/bindings/python/ns3_! module_global_routing.cc > build/debug/bindings/python/ns3_modul! e_stats.cc > build/debug/bindings/python/ns3_module_ping6.cc > build/debug/bindings/python/ns3_module_static_routing.cc > build/debug/bindings/python/ns3_module_contrib.cc > build/debug/bindings/python/ns3_module_flame.cc > build/debug/bindings/python/ns3_module_list_routing.cc > build/debug/bindings/python/ns3_module_v4ping.cc > build/debug/bindings/python/ns3_module_bridge.cc > build/debug/bindings/python/ns3_module_helper.cc > build/debug/bindings/python/ns3_module_simulator.cc > build/debug/bindings/python/ns3_module_core.cc > build/debug/bindings/python/ns3_module_csma.cc > build/debug/bindings/python/ns3_module_wifi.cc > build/debug/bindings/python/ns3_module_point_to_point.cc > build/debug/bindings/python/ns3_module_dot11s.cc > build/debug/bindings/python/ns3_module_internet_stack.cc > build/debug/bindings/python/ns3_module_virtual_net_device.cc > build/debug/bindings/python/ns3_module_tap_bridge.cc > build/debug/bindings/python/ns3_module_olsr.cc [317/905] gen_everything_h: > build/debug/ns3/system-wall-clock-ms.h build/debug/ns3/empty.h > build/debug/ns3/callback.h build/debug/ns3/object-base.h > build/debug/ns3/ref-count-base.h build/debug/ns3/type-id.h > build/debug/ns3/attribute-list.h build/debug/ns3/ptr.h > build/debug/ns3/object.h build/debug/ns3/log.h build/debug/ns3/assert.h > build/debug/ns3/breakpoint.h build/debug/ns3/fatal-error.h > build/debug/ns3/test.h build/debug/ns3/random-variable.h > build/debug/ns3/rng-stream.h build/debug/ns3/command-line.h > build/debug/ns3/type-name.h build/debug/ns3/type-traits.h > build/debug/ns3/int-to-type.h build/debug/ns3/attribute.h > build/debug/ns3/attribute-accessor-helper.h build/debug/ns3/boolean.h > build/debug/ns3/integer.h build/debug/ns3/uinteger.h > build/debug/ns3/double.h build/debug/ns3/enum.h build/debug/ns3/string.h > build/debug/ns3/pointer.h build/debug/ns3/object-factory.h > build/debug/ns3/attribute-helper.h build/debug/ns3/global-value.h > build/debug/ns3/traced-callback.h build/de! bug/ns3/traced-value.h > build/debug/ns3/trace-source-accessor.h build/debug/ns3/config.h > build/debug/ns3/object-vector.h build/debug/ns3/deprecated.h > build/debug/ns3/abort.h build/debug/ns3/names.h build/debug/ns3/vector.h > build/debug/ns3/system-mutex.h build/debug/ns3/system-thread.h > build/debug/ns3/system-condition.h build/debug/ns3/buffer.h > build/debug/ns3/chunk.h build/debug/ns3/header.h build/debug/ns3/trailer.h > build/debug/ns3/packet.h build/debug/ns3/packet-metadata.h > build/debug/ns3/pcap-writer.h build/debug/ns3/data-rate.h > build/debug/ns3/error-model.h build/debug/ns3/tag.h > build/debug/ns3/byte-tag-list.h build/debug/ns3/tag-buffer.h > build/debug/ns3/packet-tag-list.h build/debug/ns3/nix-vector.h > build/debug/ns3/ascii-writer.h build/debug/ns3/sgi-hashmap.h > build/debug/ns3/pcap-file.h build/debug/ns3/high-precision.h > build/debug/ns3/nstime.h build/debug/ns3/event-id.h > build/debug/ns3/event-impl.h build/debug/ns3/simulator.h > build/debug/ns3/simulator-impl.h build/debug! /ns3/default-simulator-impl.h > build/debug/ns3/scheduler.h buil! d/debug/ns3/list-scheduler.h > build/debug/ns3/map-scheduler.h build/debug/ns3/heap-scheduler.h > build/debug/ns3/calendar-scheduler.h > build/debug/ns3/ns2-calendar-scheduler.h > build/debug/ns3/simulation-singleton.h build/debug/ns3/timer.h > build/debug/ns3/timer-impl.h build/debug/ns3/watchdog.h > build/debug/ns3/synchronizer.h build/debug/ns3/make-event.h > build/debug/ns3/high-precision-128.h build/debug/ns3/cairo-wideint-private.h > build/debug/ns3/realtime-simulator-impl.h > build/debug/ns3/wall-clock-synchronizer.h > build/debug/ns3/event-garbage-collector.h build/debug/ns3/gnuplot.h > build/debug/ns3/delay-jitter-estimation.h build/debug/ns3/file-config.h > build/debug/ns3/config-store.h build/debug/ns3/flow-id-tag.h > build/debug/ns3/address.h build/debug/ns3/mac48-address.h > build/debug/ns3/mac64-address.h build/debug/ns3/inet-socket-address.h > build/debug/ns3/packet-socket-address.h build/debug/ns3/node.h > build/debug/ns3/ipv4-address.h build/debug/ns3/ipv4-interface-address.h > build/debug/! ns3/ipv4-address-generator.h build/debug/ns3/ipv4-header.h > build/debug/ns3/net-device.h build/debug/ns3/address-utils.h > build/debug/ns3/ipv4-route.h build/debug/ns3/ipv4-routing-protocol.h > build/debug/ns3/queue.h build/debug/ns3/drop-tail-queue.h > build/debug/ns3/llc-snap-header.h build/debug/ns3/ethernet-header.h > build/debug/ns3/ethernet-trailer.h build/debug/ns3/channel.h > build/debug/ns3/node-list.h build/debug/ns3/socket.h > build/debug/ns3/socket-factory.h build/debug/ns3/packet-socket-factory.h > build/debug/ns3/udp-socket.h build/debug/ns3/udp-socket-factory.h > build/debug/ns3/tcp-socket.h build/debug/ns3/tcp-socket-factory.h > build/debug/ns3/ipv4.h build/debug/ns3/ipv4-raw-socket-factory.h > build/debug/ns3/application.h build/debug/ns3/simple-channel.h > build/debug/ns3/simple-net-device.h build/debug/ns3/inet6-socket-address.h > build/debug/ns3/ipv6-address.h build/debug/ns3/ipv6-header.h > build/debug/ns3/ipv6-interface-address.h build/debug/ns3/ipv6-route.h > build/debug/ns3/ipv6! .h build/debug/ns3/ipv6-raw-socket-factory.h > build/debug/ns3/ipv6-routi! ng-protocol.h build/debug/ns3/packetbb.h > build/debug/ns3/udp-header.h build/debug/ns3/tcp-header.h > build/debug/ns3/sequence-number.h build/debug/ns3/icmpv4.h > build/debug/ns3/icmpv6-header.h build/debug/ns3/ipv4-l3-protocol.h > build/debug/ns3/ipv6-l3-protocol.h build/debug/ns3/arp-l3-protocol.h > build/debug/ns3/udp-l4-protocol.h build/debug/ns3/tcp-l4-protocol.h > build/debug/ns3/icmpv4-l4-protocol.h build/debug/ns3/ipv4-l4-protocol.h > build/debug/ns3/arp-cache.h build/debug/ns3/icmpv6-l4-protocol.h > build/debug/ns3/ipv6-l4-protocol.h build/debug/ns3/ndisc-cache.h > build/debug/ns3/point-to-point-net-device.h > build/debug/ns3/point-to-point-channel.h build/debug/ns3/ppp-header.h > build/debug/ns3/backoff.h build/debug/ns3/csma-net-device.h > build/debug/ns3/csma-channel.h build/debug/ns3/emu.h > build/debug/ns3/emu-net-device.h build/debug/ns3/bridge-net-device.h > build/debug/ns3/bridge-channel.h build/debug/ns3/tap.h > build/debug/ns3/tap-bridge.h build/debug/ns3/virtual-net-device.h build/d! > ebug/ns3/onoff-application.h build/debug/ns3/packet-sink.h > build/debug/ns3/udp-echo-client.h build/debug/ns3/udp-echo-server.h > build/debug/ns3/ipv4-nix-vector-routing.h > build/debug/ns3/olsr-routing-protocol.h build/debug/ns3/olsr-header.h > build/debug/ns3/olsr-state.h build/debug/ns3/olsr-repositories.h > build/debug/ns3/global-router-interface.h > build/debug/ns3/global-route-manager.h build/debug/ns3/ipv4-global-routing.h > build/debug/ns3/ipv4-static-routing.h > build/debug/ns3/ipv4-routing-table-entry.h > build/debug/ns3/ipv6-static-routing.h > build/debug/ns3/ipv6-routing-table-entry.h > build/debug/ns3/ipv4-list-routing.h build/debug/ns3/ipv6-list-routing.h > build/debug/ns3/hierarchical-mobility-model.h > build/debug/ns3/mobility-model.h build/debug/ns3/position-allocator.h > build/debug/ns3/rectangle.h > build/debug/ns3/constant-position-mobility-model.h > build/debug/ns3/constant-velocity-helper.h > build/debug/ns3/constant-velocity-mobility-model.h > build/debug/ns3/random-waypoint-mobility-m! odel.h > build/debug/ns3/random-walk-2d-mobility-model.h build/debug/ns3/! > random-direction-2d-mobility-model.h > build/debug/ns3/constant-acceleration-mobility-model.h > build/debug/ns3/propagation-delay-model.h > build/debug/ns3/propagation-loss-model.h > build/debug/ns3/jakes-propagation-loss-model.h > build/debug/ns3/wifi-net-device.h build/debug/ns3/wifi-channel.h > build/debug/ns3/wifi-mode.h build/debug/ns3/ssid.h > build/debug/ns3/wifi-preamble.h build/debug/ns3/wifi-phy-standard.h > build/debug/ns3/yans-wifi-phy.h build/debug/ns3/yans-wifi-channel.h > build/debug/ns3/wifi-phy.h build/debug/ns3/interference-helper.h > build/debug/ns3/wifi-remote-station-manager.h > build/debug/ns3/arf-wifi-manager.h build/debug/ns3/aarf-wifi-manager.h > build/debug/ns3/constant-rate-wifi-manager.h > build/debug/ns3/ideal-wifi-manager.h build/debug/ns3/amrr-wifi-manager.h > build/debug/ns3/onoe-wifi-manager.h build/debug/ns3/rraa-wifi-manager.h > build/debug/ns3/wifi-mac.h build/debug/ns3/adhoc-wifi-mac.h > build/debug/ns3/nqsta-wifi-mac.h build/debug/ns3/nqap-wifi-mac.h > build/debug/ns3/w! ifi-phy.h build/debug/ns3/supported-rates.h > build/debug/ns3/error-rate-model.h build/debug/ns3/yans-error-rate-model.h > build/debug/ns3/dca-txop.h build/debug/ns3/wifi-mac-header.h > build/debug/ns3/qadhoc-wifi-mac.h build/debug/ns3/qap-wifi-mac.h > build/debug/ns3/qsta-wifi-mac.h build/debug/ns3/qos-utils.h > build/debug/ns3/edca-txop-n.h build/debug/ns3/msdu-aggregator.h > build/debug/ns3/amsdu-subframe-header.h build/debug/ns3/qos-tag.h > build/debug/ns3/mgt-headers.h build/debug/ns3/status-code.h > build/debug/ns3/capability-information.h build/debug/ns3/dcf-manager.h > build/debug/ns3/mac-rx-middle.h build/debug/ns3/mac-low.h > build/debug/ns3/minstrel-wifi-manager.h build/debug/ns3/dcf.h > build/debug/ns3/node-container.h build/debug/ns3/net-device-container.h > build/debug/ns3/wifi-helper.h build/debug/ns3/olsr-helper.h > build/debug/ns3/point-to-point-helper.h build/debug/ns3/csma-helper.h > build/debug/ns3/mobility-helper.h build/debug/ns3/ns2-mobility-helper.h > build/debug/ns3/ipv4-address! -helper.h > build/debug/ns3/ipv4-static-routing-helper.h build/debug/ns3/! > internet-stack-helper.h build/debug/ns3/application-container.h > build/debug/ns3/on-off-helper.h build/debug/ns3/packet-sink-helper.h > build/debug/ns3/packet-socket-helper.h > build/debug/ns3/ipv4-interface-container.h build/debug/ns3/udp-echo-helper.h > build/debug/ns3/bridge-helper.h build/debug/ns3/yans-wifi-helper.h > build/debug/ns3/v4ping-helper.h build/debug/ns3/nqos-wifi-mac-helper.h > build/debug/ns3/qos-wifi-mac-helper.h > build/debug/ns3/ipv4-nix-vector-helper.h > build/debug/ns3/ipv4-global-routing-helper.h > build/debug/ns3/ipv4-list-routing-helper.h > build/debug/ns3/ipv4-routing-helper.h build/debug/ns3/mesh-helper.h > build/debug/ns3/mesh-stack-installer.h build/debug/ns3/dot11s-installer.h > build/debug/ns3/flame-installer.h build/debug/ns3/athstats-helper.h > build/debug/ns3/ipv6-address-helper.h > build/debug/ns3/ipv6-interface-container.h > build/debug/ns3/ipv6-static-routing-helper.h > build/debug/ns3/ipv6-list-routing-helper.h > build/debug/ns3/ipv6-routing-helper.h build/debug/ns3/p! ing6-helper.h > build/debug/ns3/flow-monitor-helper.h build/debug/ns3/emu-helper.h > build/debug/ns3/tap-bridge-helper.h build/debug/ns3/data-calculator.h > build/debug/ns3/packet-data-calculators.h > build/debug/ns3/time-data-calculators.h > build/debug/ns3/basic-data-calculators.h > build/debug/ns3/data-output-interface.h build/debug/ns3/omnet-data-output.h > build/debug/ns3/data-collector.h build/debug/ns3/v4ping.h > build/debug/ns3/wifi-information-element-vector.h > build/debug/ns3/mesh-point-device.h > build/debug/ns3/mesh-l2-routing-protocol.h > build/debug/ns3/mesh-wifi-beacon.h build/debug/ns3/mesh-wifi-interface-mac.h > build/debug/ns3/mesh-wifi-interface-mac-plugin.h > build/debug/ns3/hwmp-protocol.h build/debug/ns3/peer-management-protocol.h > build/debug/ns3/ie-dot11s-beacon-timing.h > build/debug/ns3/ie-dot11s-configuration.h > build/debug/ns3/ie-dot11s-peer-management.h build/debug/ns3/ie-dot11s-id.h > build/debug/ns3/peer-link.h build/debug/ns3/flame-protocol.h > build/debug/ns3/ping6.h build/! debug/ns3/radvd.h > build/debug/ns3/radvd-interface.h build/debug/ns3/rad! vd-prefix.h > build/debug/ns3/ns3tcp.h build/debug/ns3/ns3wifi.h > build/debug/ns3/flow-monitor.h build/debug/ns3/flow-probe.h > build/debug/ns3/flow-classifier.h build/debug/ns3/ipv4-flow-classifier.h > build/debug/ns3/ipv4-flow-probe.h build/debug/ns3/histogram.h > build/debug/ns3/point-to-point-dumbbell-helper.h > build/debug/ns3/point-to-point-grid-helper.h > build/debug/ns3/animation-interface.h build/debug/ns3/node-location.h -> > build/debug/bindings/python/everything.h [318/905] gen_ns3_module_header: > build/debug/ns3/system-wall-clock-ms.h build/debug/ns3/empty.h > build/debug/ns3/callback.h build/debug/ns3/object-base.h > build/debug/ns3/ref-count-base.h build/debug/ns3/type-id.h > build/debug/ns3/attribute-list.h build/debug/ns3/ptr.h > build/debug/ns3/object.h build/debug/ns3/log.h build/debug/ns3/assert.h > build/debug/ns3/breakpoint.h build/debug/ns3/fatal-error.h > build/debug/ns3/test.h build/debug/ns3/random-variable.h > build/debug/ns3/rng-stream.h build/debug/ns3/command-line.h > build/debug/ns3/type-name.h build/debug/ns3/type-traits.h > build/debug/ns3/int-to-type.h build/debug/ns3/attribute.h > build/debug/ns3/attribute-accessor-helper.h build/debug/ns3/boolean.h > build/debug/ns3/integer.h build/debug/ns3/uinteger.h > build/debug/ns3/double.h build/debug/ns3/enum.h build/debug/ns3/string.h > build/debug/ns3/pointer.h build/debug/ns3/object-factory.h > build/debug/ns3/attribute-helper.h build/debug/ns3/global-value.h > build/debug/ns3/traced-callback.h bui! ld/debug/ns3/traced-value.h > build/debug/ns3/trace-source-accessor.h build/debug/ns3/config.h > build/debug/ns3/object-vector.h build/debug/ns3/deprecated.h > build/debug/ns3/abort.h build/debug/ns3/names.h build/debug/ns3/vector.h > build/debug/ns3/system-mutex.h build/debug/ns3/system-thread.h > build/debug/ns3/system-condition.h -> build/debug/ns3/core-module.h > [319/905] gen_ns3_module_header: build/debug/ns3/buffer.h > build/debug/ns3/chunk.h build/debug/ns3/header.h build/debug/ns3/trailer.h > build/debug/ns3/packet.h build/debug/ns3/packet-metadata.h > build/debug/ns3/pcap-writer.h build/debug/ns3/data-rate.h > build/debug/ns3/error-model.h build/debug/ns3/tag.h > build/debug/ns3/byte-tag-list.h build/debug/ns3/tag-buffer.h > build/debug/ns3/packet-tag-list.h build/debug/ns3/nix-vector.h > build/debug/ns3/ascii-writer.h build/debug/ns3/sgi-hashmap.h > build/debug/ns3/pcap-file.h -> build/debug/ns3/common-module.h [320/905] > gen_ns3_module_header: build/debug/ns3/high-precision.h > build/debug/ns3/nstime.h build/debug/ns3/event-id.h > build/debug/ns3/event-impl.h build/debug/ns3/simulator.h > build/debug/ns3/simulator-impl.h build/debug/ns3/default-simulator-impl.h > build/debug/ns3/scheduler.h build/debug/ns3/list-scheduler.h > build/debug/ns3/map-scheduler.h build/debug/ns3/heap-scheduler.h > build/debug/ns3/calendar-scheduler.h > build/debug/ns3/ns2-calendar-scheduler.h > build/debug/ns3/simulation-singleton.h build/debug/ns3/timer.h > build/debug/ns3/timer-impl.h build/debug/ns3/watchdog.h > build/debug/ns3/synchronizer.h build/debug/ns3/make-event.h > build/debug/ns3/high-precision-128.h build/debug/ns3/cairo-wideint-private.h > build/debug/ns3/realtime-simulator-impl.h > build/debug/ns3/wall-clock-synchronizer.h -> > build/debug/ns3/simulator-module.h [321/905] gen_ns3_module_header: > build/debug/ns3/event-garbage-collector.h build/debug/ns3/gnuplot.h > build/debug/ns3/delay-jitter-estimation.h build/debug/ns3/file-config.h > build/debug/ns3/config-store.h build/debug/ns3/flow-id-tag.h -> > build/debug/ns3/contrib-module.h [322/905] gen_ns3_module_header: > build/debug/ns3/address.h build/debug/ns3/mac48-address.h > build/debug/ns3/mac64-address.h build/debug/ns3/inet-socket-address.h > build/debug/ns3/packet-socket-address.h build/debug/ns3/node.h > build/debug/ns3/ipv4-address.h build/debug/ns3/ipv4-interface-address.h > build/debug/ns3/ipv4-address-generator.h build/debug/ns3/ipv4-header.h > build/debug/ns3/net-device.h build/debug/ns3/address-utils.h > build/debug/ns3/ipv4-route.h build/debug/ns3/ipv4-routing-protocol.h > build/debug/ns3/queue.h build/debug/ns3/drop-tail-queue.h > build/debug/ns3/llc-snap-header.h build/debug/ns3/ethernet-header.h > build/debug/ns3/ethernet-trailer.h build/debug/ns3/channel.h > build/debug/ns3/node-list.h build/debug/ns3/socket.h > build/debug/ns3/socket-factory.h build/debug/ns3/packet-socket-factory.h > build/debug/ns3/udp-socket.h build/debug/ns3/udp-socket-factory.h > build/debug/ns3/tcp-socket.h build/debug/ns3/tcp-socket-factory.h > build/debug/ns3/ipv4.h build/debug/ns3/ipv4-raw! -socket-factory.h > build/debug/ns3/application.h build/debug/ns3/simple-channel.h > build/debug/ns3/simple-net-device.h build/debug/ns3/inet6-socket-address.h > build/debug/ns3/ipv6-address.h build/debug/ns3/ipv6-header.h > build/debug/ns3/ipv6-interface-address.h build/debug/ns3/ipv6-route.h > build/debug/ns3/ipv6.h build/debug/ns3/ipv6-raw-socket-factory.h > build/debug/ns3/ipv6-routing-protocol.h build/debug/ns3/packetbb.h -> > build/debug/ns3/node-module.h [323/905] gen_ns3_module_header: > build/debug/ns3/udp-header.h build/debug/ns3/tcp-header.h > build/debug/ns3/sequence-number.h build/debug/ns3/icmpv4.h > build/debug/ns3/icmpv6-header.h build/debug/ns3/ipv4-l3-protocol.h > build/debug/ns3/ipv6-l3-protocol.h build/debug/ns3/arp-l3-protocol.h > build/debug/ns3/udp-l4-protocol.h build/debug/ns3/tcp-l4-protocol.h > build/debug/ns3/icmpv4-l4-protocol.h build/debug/ns3/ipv4-l4-protocol.h > build/debug/ns3/arp-cache.h build/debug/ns3/icmpv6-l4-protocol.h > build/debug/ns3/ipv6-l4-protocol.h build/debug/ns3/ndisc-cache.h -> > build/debug/ns3/internet-stack-module.h [324/905] gen_ns3_module_header: > build/debug/ns3/point-to-point-net-device.h > build/debug/ns3/point-to-point-channel.h build/debug/ns3/ppp-header.h -> > build/debug/ns3/point-to-point-module.h [325/905] gen_ns3_module_header: > build/debug/ns3/backoff.h build/debug/ns3/csma-net-device.h > build/debug/ns3/csma-channel.h -> build/debug/ns3/csma-module.h [326/905] > gen_ns3_module_header: build/debug/ns3/emu.h > build/debug/ns3/emu-net-device.h -> build/debug/ns3/emu-module.h [327/905] > gen_ns3_module_header: build/debug/ns3/bridge-net-device.h > build/debug/ns3/bridge-channel.h -> build/debug/ns3/bridge-module.h > [328/905] gen_ns3_module_header: build/debug/ns3/tap.h > build/debug/ns3/tap-bridge.h -> build/debug/ns3/tap-bridge-module.h > [329/905] gen_ns3_module_header: build/debug/ns3/virtual-net-device.h -> > build/debug/ns3/virtual-net-device-module.h [330/905] gen_ns3_module_header: > build/debug/ns3/onoff-application.h -> build/debug/ns3/onoff-module.h > [331/905] gen_ns3_module_header: build/debug/ns3/packet-sink.h -> > build/debug/ns3/packet-sink-module.h [332/905] gen_ns3_module_header: > build/debug/ns3/udp-echo-client.h build/debug/ns3/udp-echo-server.h -> > build/debug/ns3/udp-echo-module.h [333/905] gen_ns3_module_header: > build/debug/ns3/ipv4-nix-vector-routing.h -> > build/debug/ns3/nix-vector-routing-module.h [334/905] gen_ns3_module_header: > build/debug/ns3/olsr-routing-protocol.h build/debug/ns3/olsr-header.h > build/debug/ns3/olsr-state.h build/debug/ns3/olsr-repositories.h -> > build/debug/ns3/olsr-module.h [335/905] gen_ns3_module_header: > build/debug/ns3/global-router-interface.h > build/debug/ns3/global-route-manager.h build/debug/ns3/ipv4-global-routing.h > -> build/debug/ns3/global-routing-module.h [336/905] gen_ns3_module_header: > build/debug/ns3/ipv4-static-routing.h > build/debug/ns3/ipv4-routing-table-entry.h > build/debug/ns3/ipv6-static-routing.h > build/debug/ns3/ipv6-routing-table-entry.h -> > build/debug/ns3/static-routing-module.h [337/905] gen_ns3_module_header: > build/debug/ns3/ipv4-list-routing.h build/debug/ns3/ipv6-list-routing.h -> > build/debug/ns3/list-routing-module.h [338/905] gen_ns3_module_header: > build/debug/ns3/hierarchical-mobility-model.h > build/debug/ns3/mobility-model.h build/debug/ns3/position-allocator.h > build/debug/ns3/rectangle.h > build/debug/ns3/constant-position-mobility-model.h > build/debug/ns3/constant-velocity-helper.h > build/debug/ns3/constant-velocity-mobility-model.h > build/debug/ns3/random-waypoint-mobility-model.h > build/debug/ns3/random-walk-2d-mobility-model.h > build/debug/ns3/random-direction-2d-mobility-model.h > build/debug/ns3/constant-acceleration-mobility-model.h -> > build/debug/ns3/mobility-module.h [339/905] gen_ns3_module_header: > build/debug/ns3/propagation-delay-model.h > build/debug/ns3/propagation-loss-model.h > build/debug/ns3/jakes-propagation-loss-model.h > build/debug/ns3/wifi-net-device.h build/debug/ns3/wifi-channel.h > build/debug/ns3/wifi-mode.h build/debug/ns3/ssid.h > build/debug/ns3/wifi-preamble.h build/debug/ns3/wifi-phy-standard.h > build/debug/ns3/yans-wifi-phy.h build/debug/ns3/yans-wifi-channel.h > build/debug/ns3/wifi-phy.h build/debug/ns3/interference-helper.h > build/debug/ns3/wifi-remote-station-manager.h > build/debug/ns3/arf-wifi-manager.h build/debug/ns3/aarf-wifi-manager.h > build/debug/ns3/constant-rate-wifi-manager.h > build/debug/ns3/ideal-wifi-manager.h build/debug/ns3/amrr-wifi-manager.h > build/debug/ns3/onoe-wifi-manager.h build/debug/ns3/rraa-wifi-manager.h > build/debug/ns3/wifi-mac.h build/debug/ns3/adhoc-wifi-mac.h > build/debug/ns3/nqsta-wifi-mac.h build/debug/ns3/nqap-wifi-mac.h > build/debug/ns3/wifi-phy.h build/debug/ns3/supported-rates.h > build/debug/ns3/! error-rate-model.h build/debug/ns3/yans-error-rate-model.h > build/debug/ns3/dca-txop.h build/debug/ns3/wifi-mac-header.h > build/debug/ns3/qadhoc-wifi-mac.h build/debug/ns3/qap-wifi-mac.h > build/debug/ns3/qsta-wifi-mac.h build/debug/ns3/qos-utils.h > build/debug/ns3/edca-txop-n.h build/debug/ns3/msdu-aggregator.h > build/debug/ns3/amsdu-subframe-header.h build/debug/ns3/qos-tag.h > build/debug/ns3/mgt-headers.h build/debug/ns3/status-code.h > build/debug/ns3/capability-information.h build/debug/ns3/dcf-manager.h > build/debug/ns3/mac-rx-middle.h build/debug/ns3/mac-low.h > build/debug/ns3/minstrel-wifi-manager.h build/debug/ns3/dcf.h -> > build/debug/ns3/wifi-module.h [340/905] gen_ns3_module_header: > build/debug/ns3/node-container.h build/debug/ns3/net-device-container.h > build/debug/ns3/wifi-helper.h build/debug/ns3/olsr-helper.h > build/debug/ns3/point-to-point-helper.h build/debug/ns3/csma-helper.h > build/debug/ns3/mobility-helper.h build/debug/ns3/ns2-mobility-helper.h > build/debug/ns3/ipv4-address-helper.h > build/debug/ns3/ipv4-static-routing-helper.h > build/debug/ns3/internet-stack-helper.h > build/debug/ns3/application-container.h build/debug/ns3/on-off-helper.h > build/debug/ns3/packet-sink-helper.h build/debug/ns3/packet-socket-helper.h > build/debug/ns3/ipv4-interface-container.h build/debug/ns3/udp-echo-helper.h > build/debug/ns3/bridge-helper.h build/debug/ns3/yans-wifi-helper.h > build/debug/ns3/v4ping-helper.h build/debug/ns3/nqos-wifi-mac-helper.h > build/debug/ns3/qos-wifi-mac-helper.h > build/debug/ns3/ipv4-nix-vector-helper.h > build/debug/ns3/ipv4-global-routing-helper.h > build/debug/ns3/ipv4-list-routing-helper.h build/debug/ns3/ipv4-routing-! > helper.h build/debug/ns3/mesh-helper.h > build/debug/ns3/mesh-stack-installer.h build/debug/ns3/dot11s-installer.h > build/debug/ns3/flame-installer.h build/debug/ns3/athstats-helper.h > build/debug/ns3/ipv6-address-helper.h > build/debug/ns3/ipv6-interface-container.h > build/debug/ns3/ipv6-static-routing-helper.h > build/debug/ns3/ipv6-list-routing-helper.h > build/debug/ns3/ipv6-routing-helper.h build/debug/ns3/ping6-helper.h > build/debug/ns3/flow-monitor-helper.h build/debug/ns3/emu-helper.h > build/debug/ns3/tap-bridge-helper.h -> build/debug/ns3/helper-module.h > [341/905] gen_ns3_module_header: build/debug/ns3/data-calculator.h > build/debug/ns3/packet-data-calculators.h > build/debug/ns3/time-data-calculators.h > build/debug/ns3/basic-data-calculators.h > build/debug/ns3/data-output-interface.h build/debug/ns3/omnet-data-output.h > build/debug/ns3/data-collector.h -> build/debug/ns3/stats-module.h [342/905] > gen_ns3_module_header: build/debug/ns3/v4ping.h -> > build/debug/ns3/v4ping-module.h [343/905] gen_ns3_module_header: > build/debug/ns3/wifi-information-element-vector.h > build/debug/ns3/mesh-point-device.h > build/debug/ns3/mesh-l2-routing-protocol.h > build/debug/ns3/mesh-wifi-beacon.h build/debug/ns3/mesh-wifi-interface-mac.h > build/debug/ns3/mesh-wifi-interface-mac-plugin.h -> > build/debug/ns3/mesh-module.h [344/905] gen_ns3_module_header: > build/debug/ns3/hwmp-protocol.h build/debug/ns3/peer-management-protocol.h > build/debug/ns3/ie-dot11s-beacon-timing.h > build/debug/ns3/ie-dot11s-configuration.h > build/debug/ns3/ie-dot11s-peer-management.h build/debug/ns3/ie-dot11s-id.h > build/debug/ns3/peer-link.h -> build/debug/ns3/dot11s-module.h [345/905] > gen_ns3_module_header: build/debug/ns3/flame-protocol.h -> > build/debug/ns3/flame-module.h [346/905] gen_ns3_module_header: > build/debug/ns3/ping6.h -> build/debug/ns3/ping6-module.h [347/905] > gen_ns3_module_header: build/debug/ns3/radvd.h > build/debug/ns3/radvd-interface.h build/debug/ns3/radvd-prefix.h -> > build/debug/ns3/radvd-module.h [348/905] gen_ns3_module_header: > build/debug/ns3/ns3tcp.h -> build/debug/ns3/ns3tcp-module.h [349/905] > gen_ns3_module_header: build/debug/ns3/ns3wifi.h -> > build/debug/ns3/ns3wifi-module.h [350/905] gen_ns3_module_header: > build/debug/ns3/flow-monitor.h build/debug/ns3/flow-probe.h > build/debug/ns3/flow-classifier.h build/debug/ns3/ipv4-flow-classifier.h > build/debug/ns3/ipv4-flow-probe.h build/debug/ns3/histogram.h -> > build/debug/ns3/flow-monitor-module.h [351/905] gen_ns3_module_header: > build/debug/ns3/point-to-point-dumbbell-helper.h > build/debug/ns3/point-to-point-grid-helper.h > build/debug/ns3/animation-interface.h build/debug/ns3/node-location.h -> > build/debug/ns3/net-anim-module.h [352/905] cxx: src/core/callback-test.cc > -> build/debug/src/core/callback-test_1.o [353/905] cxx: src/core/log.cc -> > build/debug/src/core/log_1.o [354/905] cxx: src/core/breakpoint.cc -> > build/debug/src/core/breakpoint_1.o [355/905] cxx: src/core/type-id.cc -> > build/debug/src/core/type-id_1.o [356/905] cxx: src/core/attribute-list.cc > -> build/debug/src/core/attribute-list_1.o [357/905] cxx: > src/core/object-base.cc -> build/debug/src/core/object-base_1.o [358/905] > cxx: src/core/ref-count-base.cc -> build/debug/src/core/ref-count-base_1.o > [359/905] cxx: src/core/ptr.cc -> build/debug/src/core/ptr_1.o [360/905] > cxx: src/core/object.cc -> build/debug/src/core/object_1.o [361/905] cxx: > src/core/test.cc -> build/debug/src/core/test_1.o [362/905] cxx: > src/core/random-variable.cc -> build/debug/src/core/random-variable_1.o > [363/905] cxx: src/core/rng-stream.cc -> build/debug/src/core/rng-stream_1.o > [364/905] cxx: src/core/command-line.cc -> > build/debug/src/core/command-line_1.o [365/905] cxx: src/core/type-name.cc > -> build/debug/src/core/type-name_1.o [366/905] cxx: > src/core/type-traits-test.cc -> build/debug/src/core/type-traits-test_1.o > [367/905] cxx: src/core/attribute.cc -> build/debug/src/core/attribute_1.o > [368/905] cxx: src/core/boolean.cc -> build/debug/src/core/boolean_1.o > [369/905] cxx: src/core/integer.cc -> build/debug/src/core/integer_1.o > [370/905] cxx: src/core/uinteger.cc -> build/debug/src/core/uinteger_1.o > [371/905] cxx: src/core/enum.cc -> build/debug/src/core/enum_1.o [372/905] > cxx: src/core/double.cc -> build/debug/src/core/double_1.o [373/905] cxx: > src/core/string.cc -> build/debug/src/core/string_1.o [374/905] cxx: > src/core/pointer.cc -> build/debug/src/core/pointer_1.o [375/905] cxx: > src/core/object-vector.cc -> build/debug/src/core/object-vector_1.o > [376/905] cxx: src/core/attribute-test.cc -> > build/debug/src/core/attribute-test_1.o [377/905] cxx: > src/core/object-factory.cc -> build/debug/src/core/object-factory_1.o > [378/905] cxx: src/core/global-value.cc -> > build/debug/src/core/global-value_1.o [379/905] cxx: > src/core/traced-callback.cc -> build/debug/src/core/traced-callback_1.o > [380/905] cxx: src/core/trace-source-accessor.cc -> > build/debug/src/core/trace-source-accessor_1.o [381/905] cxx: > src/core/config.cc -> build/debug/src/core/config_1.o [382/905] cxx: > src/core/callback.cc -> build/debug/src/core/callback_1.o [383/905] cxx: > src/core/names.cc -> build/debug/src/core/names_1.o [384/905] cxx: > src/core/vector.cc -> build/debug/src/core/vector_1.o [385/905] cxx: > src/core/names-test-suite.cc -> build/debug/src/core/names-test-suite_1.o > [386/905] cxx: src/core/unix-system-wall-clock-ms.cc -> > build/debug/src/core/unix-system-wall-clock-ms_1.o [387/905] cxx: > src/core/unix-system-thread.cc -> > build/debug/src/core/unix-system-thread_1.o [388/905] cxx: > src/core/unix-system-mutex.cc -> build/debug/src/core/unix-system-mutex_1.o > [389/905] cxx: src/core/unix-system-condition.cc -> > build/debug/src/core/unix-system-condition_1.o [390/905] cxx: > src/common/buffer.cc -> build/debug/src/common/buffer_1.o [391/905] cxx: > src/common/packet-metadata.cc -> build/debug/src/common/packet-metadata_1.o > [392/905] cxx: src/common/packet-metadata-test.cc -> > build/debug/src/common/packet-metadata-test_1.o [393/905] cxx: > src/common/packet.cc -> build/debug/src/common/packet_1.o [394/905] cxx: > src/common/chunk.cc -> build/debug/src/common/chunk_1.o [395/905] cxx: > src/common/header.cc -> build/debug/src/common/header_1.o [396/905] cxx: > src/common/trailer.cc -> build/debug/src/common/trailer_1.o [397/905] cxx: > src/common/pcap-writer.cc -> build/debug/src/common/pcap-writer_1.o > [398/905] cxx: src/common/data-rate.cc -> > build/debug/src/common/data-rate_1.o [399/905] cxx: > src/common/error-model.cc -> build/debug/src/common/error-model_1.o > [400/905] cxx: src/common/tag.cc -> build/debug/src/common/tag_1.o [401/905] > cxx: src/common/byte-tag-list.cc -> build/debug/src/common/byte-tag-list_1.o > [402/905] cxx: src/common/tag-buffer.cc -> > build/debug/src/common/tag-buffer_1.o [403/905] cxx: > src/common/packet-tag-list.cc -> build/debug/src/common/packet-tag-list_1.o > [404/905] cxx: src/common/nix-vector.cc -> > build/debug/src/common/nix-vector_1.o [405/905] cxx: > src/common/ascii-writer.cc -> build/debug/src/common/ascii-writer_1.o > [406/905] cxx: src/common/pcap-file.cc -> > build/debug/src/common/pcap-file_1.o [407/905] cxx: > src/common/pcap-file-test-suite.cc -> > build/debug/src/common/pcap-file-test-suite_1.o [408/905] cxx: > src/simulator/high-precision.cc -> > build/debug/src/simulator/high-precision_1.o [409/905] cxx: > src/simulator/time.cc -> build/debug/src/simulator/time_1.o [410/905] cxx: > src/simulator/event-id.cc -> build/debug/src/simulator/event-id_1.o > [411/905] cxx: src/simulator/scheduler.cc -> > build/debug/src/simulator/scheduler_1.o [412/905] cxx: > src/simulator/list-scheduler.cc -> > build/debug/src/simulator/list-scheduler_1.o [413/905] cxx: > src/simulator/map-scheduler.cc -> > build/debug/src/simulator/map-scheduler_1.o [414/905] cxx: > src/simulator/heap-scheduler.cc -> > build/debug/src/simulator/heap-scheduler_1.o [415/905] cxx: > src/simulator/calendar-scheduler.cc -> > build/debug/src/simulator/calendar-scheduler_1.o [416/905] cxx: > src/simulator/ns2-calendar-scheduler.cc -> > build/debug/src/simulator/ns2-calendar-scheduler_1.o [417/905] cxx: > src/simulator/event-impl.cc -> build/debug/src/simulator/event-impl_1.o > [418/905] cxx: src/simulator/simulator.cc -> > build/debug/src/simulator/simulator_1.o [419/905] cxx: > src/simulator/default-simulator-impl.cc -> > build/debug/src/simulator/default-simulator-impl_1.o [420/905] cxx: > src/simulator/timer.cc -> build/debug/src/simulator/timer_1.o [421/905] cxx: > src/simulator/watchdog.cc -> build/debug/src/simulator/watchdog_1.o > [422/905] cxx: src/simulator/synchronizer.cc -> > build/debug/src/simulator/synchronizer_1.o [423/905] cxx: > src/simulator/make-event.cc -> build/debug/src/simulator/make-event_1.o > [424/905] cxx: src/simulator/high-precision-128.cc -> > build/debug/src/simulator/high-precision-128_1.o [425/905] cxx: > src/simulator/cairo-wideint.c -> build/debug/src/simulator/cairo-wideint_1.o > [426/905] cxx: src/simulator/realtime-simulator-impl.cc -> > build/debug/src/simulator/realtime-simulator-impl_1.o [427/905] cxx: > src/simulator/wall-clock-synchronizer.cc -> > build/debug/src/simulator/wall-clock-synchronizer_1.o [428/905] cxx: > src/contrib/event-garbage-collector.cc -> > build/debug/src/contrib/event-garbage-collector_1.o [429/905] cxx: > src/contrib/gnuplot.cc -> build/debug/src/contrib/gnuplot_1.o [430/905] cxx: > src/contrib/delay-jitter-estimation.cc -> > build/debug/src/contrib/delay-jitter-estimation_1.o [431/905] cxx: > src/contrib/attribute-iterator.cc -> > build/debug/src/contrib/attribute-iterator_1.o [432/905] cxx: > src/contrib/config-store.cc -> build/debug/src/contrib/config-store_1.o > [433/905] cxx: src/contrib/flow-id-tag.cc -> > build/debug/src/contrib/flow-id-tag_1.o [434/905] cxx: > src/contrib/attribute-default-iterator.cc -> > build/debug/src/contrib/attribute-default-iterator_1.o [435/905] cxx: > src/contrib/file-config.cc -> build/debug/src/contrib/file-config_1.o > [436/905] cxx: src/contrib/raw-text-config.cc -> > build/debug/src/contrib/raw-text-config_1.o [437/905] cxx: > src/node/address.cc -> build/debug/src/node/address_1.o [438/905] cxx: > src/node/mac48-address.cc -> build/debug/src/node/mac48-address_1.o > [439/905] cxx: src/node/mac64-address.cc -> > build/debug/src/node/mac64-address_1.o [440/905] cxx: > src/node/inet-socket-address.cc -> > build/debug/src/node/inet-socket-address_1.o [441/905] cxx: > src/node/packet-socket-address.cc -> > build/debug/src/node/packet-socket-address_1.o [442/905] cxx: > src/node/node.cc -> build/debug/src/node/node_1.o [443/905] cxx: > src/node/ipv4-address.cc -> build/debug/src/node/ipv4-address_1.o [444/905] > cxx: src/node/ipv4-interface-address.cc -> > build/debug/src/node/ipv4-interface-address_1.o [445/905] cxx: > src/node/ipv4-address-generator.cc -> > build/debug/src/node/ipv4-address-generator_1.o [446/905] cxx: > src/node/ipv4-header.cc -> build/debug/src/node/ipv4-header_1.o [447/905] > cxx: src/node/net-device.cc -> build/debug/src/node/net-device_1.o [448/905] > cxx: src/node/address-utils.cc -> build/debug/src/node/address-utils_1.o > [449/905] cxx: src/node/llc-snap-header.cc -> > build/debug/src/node/llc-snap-header_1.o [450/905] cxx: > src/node/ethernet-header.cc -> build/debug/src/node/ethernet-header_1.o > [451/905] cxx: src/node/ethernet-trailer.cc -> > build/debug/src/node/ethernet-trailer_1.o [452/905] cxx: > src/node/ipv4-route.cc -> build/debug/src/node/ipv4-route_1.o [453/905] cxx: > src/node/ipv4-routing-protocol.cc -> > build/debug/src/node/ipv4-routing-protocol_1.o [454/905] cxx: > src/node/queue.cc -> build/debug/src/node/queue_1.o [455/905] cxx: > src/node/drop-tail-queue.cc -> build/debug/src/node/drop-tail-queue_1.o > [456/905] cxx: src/node/channel.cc -> build/debug/src/node/channel_1.o > [457/905] cxx: src/node/node-list.cc -> build/debug/src/node/node-list_1.o > [458/905] cxx: src/node/socket.cc -> build/debug/src/node/socket_1.o > [459/905] cxx: src/node/socket-factory.cc -> > build/debug/src/node/socket-factory_1.o [460/905] cxx: > src/node/packet-socket-factory.cc -> > build/debug/src/node/packet-socket-factory_1.o [461/905] cxx: > src/node/packet-socket.cc -> build/debug/src/node/packet-socket_1.o > [462/905] cxx: src/node/udp-socket.cc -> build/debug/src/node/udp-socket_1.o > [463/905] cxx: src/node/udp-socket-factory.cc -> > build/debug/src/node/udp-socket-factory_1.o [464/905] cxx: > src/node/tcp-socket.cc -> build/debug/src/node/tcp-socket_1.o [465/905] cxx: > src/node/tcp-socket-factory.cc -> > build/debug/src/node/tcp-socket-factory_1.o [466/905] cxx: src/node/ipv4.cc > -> build/debug/src/node/ipv4_1.o [467/905] cxx: > src/node/ipv4-raw-socket-factory.cc -> > build/debug/src/node/ipv4-raw-socket-factory_1.o [468/905] cxx: > src/node/application.cc -> build/debug/src/node/application_1.o [469/905] > cxx: src/node/simple-channel.cc -> build/debug/src/node/simple-channel_1.o > [470/905] cxx: src/node/simple-net-device.cc -> > build/debug/src/node/simple-net-device_1.o [471/905] cxx: > src/node/inet6-socket-address.cc -> > build/debug/src/node/inet6-socket-address_1.o [472/905] cxx: > src/node/ipv6-address.cc -> build/debug/src/node/ipv6-address_1.o [473/905] > cxx: src/node/ipv6-header.cc -> build/debug/src/node/ipv6-header_1.o > [474/905] cxx: src/node/ipv6-interface-address.cc -> > build/debug/src/node/ipv6-interface-address_1.o [475/905] cxx: > src/node/ipv6-route.cc -> build/debug/src/node/ipv6-route_1.o [476/905] cxx: > src/node/ipv6.cc -> build/debug/src/node/ipv6_1.o [477/905] cxx: > src/node/ipv6-raw-socket-factory.cc -> > build/debug/src/node/ipv6-raw-socket-factory_1.o [478/905] cxx: > src/node/ipv6-routing-protocol.cc -> > build/debug/src/node/ipv6-routing-protocol_1.o [479/905] cxx: > src/node/packetbb.cc -> build/debug/src/node/packetbb_1.o [480/905] cxx: > src/internet-stack/tcp-test.cc -> > build/debug/src/internet-stack/tcp-test_1.o [481/905] cxx: > src/internet-stack/udp-test.cc -> > build/debug/src/internet-stack/udp-test_1.o [482/905] cxx: > src/internet-stack/ipv4-test.cc -> > build/debug/src/internet-stack/ipv4-test_1.o [483/905] cxx: > src/internet-stack/ipv4-l4-protocol.cc -> > build/debug/src/internet-stack/ipv4-l4-protocol_1.o [484/905] cxx: > src/internet-stack/udp-header.cc -> > build/debug/src/internet-stack/udp-header_1.o [485/905] cxx: > src/internet-stack/tcp-header.cc -> > build/debug/src/internet-stack/tcp-header_1.o [486/905] cxx: > src/internet-stack/ipv4-interface.cc -> > build/debug/src/internet-stack/ipv4-interface_1.o [487/905] cxx: > src/internet-stack/ipv4-l3-protocol.cc -> > build/debug/src/internet-stack/ipv4-l3-protocol_1.o [488/905] cxx: > src/internet-stack/ipv4-end-point.cc -> > build/debug/src/internet-stack/ipv4-end-point_1.o [489/905] cxx: > src/internet-stack/udp-l4-protocol.cc -> > build/debug/src/internet-stack/udp-l4-protocol_1.o [490/905] cxx: > src/internet-stack/tcp-l4-protocol.cc -> > build/debug/src/internet-stack/tcp-l4-protocol_1.o [491/905] cxx: > src/internet-stack/arp-header.cc -> > build/debug/src/internet-stack/arp-header_1.o [492/905] cxx: > src/internet-stack/arp-cache.cc -> > build/debug/src/internet-stack/arp-cache_1.o [493/905] cxx: > src/internet-stack/arp-l3-protocol.cc -> > build/debug/src/internet-stack/arp-l3-protocol_1.o [494/905] cxx: > src/internet-stack/udp-socket-impl.cc -> > build/debug/src/internet-stack/udp-socket-impl_1.o [495/905] cxx: > src/internet-stack/tcp-socket-impl.cc -> > build/debug/src/internet-stack/tcp-socket-impl_1.o [496/905] cxx: > src/internet-stack/ipv4-end-point-demux.cc -> > build/debug/src/internet-stack/ipv4-end-point-demux_1.o [497/905] cxx: > src/internet-stack/udp-socket-factory-impl.cc -> > build/debug/src/internet-stack/udp-socket-factory-impl_1.o [498/905] cxx: > src/internet-stack/tcp-socket-factory-impl.cc -> > build/debug/src/internet-stack/tcp-socket-factory-impl_1.o [499/905] cxx: > src/internet-stack/pending-data.cc -> > build/debug/src/internet-stack/pending-data_1.o [500/905] cxx: > src/internet-stack/sequence-number.cc -> > build/debug/src/internet-stack/sequence-number_1.o [501/905] cxx: > src/internet-stack/rtt-estimator.cc -> > build/debug/src/internet-stack/rtt-estimator_1.o [502/905] cxx: > src/internet-stack/ipv4-raw-socket-factory-impl.cc -> > build/debug/src/internet-stack/ipv4-raw-socket-factory-impl_1.o [503/905] > cxx: src/internet-stack/ipv4-raw-socket-impl.cc -> > build/debug/src/internet-stack/ipv4-raw-socket-impl_1.o [504/905] cxx: > src/internet-stack/icmpv4.cc -> build/debug/src/internet-stack/icmpv4_1.o > [505/905] cxx: src/internet-stack/icmpv4-l4-protocol.cc -> > build/debug/src/internet-stack/icmpv4-l4-protocol_1.o [506/905] cxx: > src/internet-stack/loopback-net-device.cc -> > build/debug/src/internet-stack/loopback-net-device_1.o [507/905] cxx: > src/internet-stack/ipv6-interface.cc -> > build/debug/src/internet-stack/ipv6-interface_1.o [508/905] cxx: > src/internet-stack/ndisc-cache.cc -> > build/debug/src/internet-stack/ndisc-cache_1.o [509/905] cxx: > src/internet-stack/icmpv6-header.cc -> > build/debug/src/internet-stack/icmpv6-header_1.o [510/905] cxx: > src/internet-stack/ipv6-l3-protocol.cc -> > build/debug/src/internet-stack/ipv6-l3-protocol_1.o [511/905] cxx: > src/internet-stack/ipv6-end-point.cc -> > build/debug/src/internet-stack/ipv6-end-point_1.o [512/905] cxx: > src/internet-stack/ipv6-end-point-demux.cc -> > build/debug/src/internet-stack/ipv6-end-point-demux_1.o [513/905] cxx: > src/internet-stack/ipv6-l4-protocol.cc -> > build/debug/src/internet-stack/ipv6-l4-protocol_1.o [514/905] cxx: > src/internet-stack/ipv6-raw-socket-factory-impl.cc -> > build/debug/src/internet-stack/ipv6-raw-socket-factory-impl_1.o [515/905] > cxx: src/internet-stack/ipv6-raw-socket-impl.cc -> > build/debug/src/internet-stack/ipv6-raw-socket-impl_1.o [516/905] cxx: > src/internet-stack/ipv6-autoconfigured-prefix.cc -> > build/debug/src/internet-stack/ipv6-autoconfigured-prefix_1.o [517/905] cxx: > src/internet-stack/icmpv6-l4-protocol.cc -> > build/debug/src/internet-stack/icmpv6-l4-protocol_1.o [518/905] cxx: > src/internet-stack/ipv6-test.cc -> > build/debug/src/internet-stack/ipv6-test_1.o [519/905] cxx: > src/devices/point-to-point/point-to-point-net-device.cc -> > build/debug/src/devices/point-to-point/point-to-point-net-device_1.o > [520/905] cxx: src/devices/point-to-point/point-to-point-channel.cc -> > build/debug/src/devices/point-to-point/point-to-point-channel_1.o [521/905] > cxx: src/devices/point-to-point/point-to-point-test.cc -> > build/debug/src/devices/point-to-point/point-to-point-test_1.o [522/905] > cxx: src/devices/point-to-point/ppp-header.cc -> > build/debug/src/devices/point-to-point/ppp-header_1.o [523/905] cxx: > src/devices/csma/backoff.cc -> build/debug/src/devices/csma/backoff_1.o > [524/905] cxx: src/devices/csma/csma-net-device.cc -> > build/debug/src/devices/csma/csma-net-device_1.o [525/905] cxx: > src/devices/csma/csma-channel.cc -> > build/debug/src/devices/csma/csma-channel_1.o [526/905] cxx: > src/devices/emu/emu-net-device.cc -> > build/debug/src/devices/emu/emu-net-device_1.o [527/905] cxx: > src/devices/emu/emu-encode-decode.cc -> > build/debug/src/devices/emu/emu-encode-decode_1.o [528/905] cxx: > src/devices/emu/emu-sock-creator.cc -> > build/debug/src/devices/emu/emu-sock-creator_3.o [529/905] cxx: > src/devices/emu/emu-encode-decode.cc -> > build/debug/src/devices/emu/emu-encode-decode_3.o [530/905] cxx: > src/devices/bridge/bridge-net-device.cc -> > build/debug/src/devices/bridge/bridge-net-device_1.o [531/905] cxx: > src/devices/bridge/bridge-channel.cc -> > build/debug/src/devices/bridge/bridge-channel_1.o [532/905] cxx: > src/devices/tap-bridge/tap-bridge.cc -> > build/debug/src/devices/tap-bridge/tap-bridge_1.o [533/905] cxx: > src/devices/tap-bridge/tap-encode-decode.cc -> > build/debug/src/devices/tap-bridge/tap-encode-decode_1.o [534/905] cxx: > src/devices/tap-bridge/tap-creator.cc -> > build/debug/src/devices/tap-bridge/tap-creator_3.o [535/905] cxx: > src/devices/tap-bridge/tap-encode-decode.cc -> > build/debug/src/devices/tap-bridge/tap-encode-decode_3.o [536/905] cxx: > src/devices/virtual-net-device/virtual-net-device.cc -> > build/debug/src/devices/virtual-net-device/virtual-net-device_1.o [537/905] > cxx: src/applications/onoff/onoff-application.cc -> > build/debug/src/applications/onoff/onoff-application_1.o [538/905] cxx: > src/applications/packet-sink/packet-sink.cc -> > build/debug/src/applications/packet-sink/packet-sink_1.o [539/905] cxx: > src/applications/udp-echo/udp-echo-client.cc -> > build/debug/src/applications/udp-echo/udp-echo-client_1.o [540/905] cxx: > src/applications/udp-echo/udp-echo-server.cc -> > build/debug/src/applications/udp-echo/udp-echo-server_1.o [541/905] cxx: > src/routing/nix-vector-routing/ipv4-nix-vector-routing.cc -> > build/debug/src/routing/nix-vector-routing/ipv4-nix-vector-routing_1.o > [542/905] cxx: src/routing/olsr/olsr-header.cc -> > build/debug/src/routing/olsr/olsr-header_1.o [543/905] cxx: > src/routing/olsr/olsr-state.cc -> > build/debug/src/routing/olsr/olsr-state_1.o [544/905] cxx: > src/routing/olsr/olsr-routing-protocol.cc -> > build/debug/src/routing/olsr/olsr-routing-protocol_1.o [545/905] cxx: > src/routing/global-routing/global-router-interface.cc -> > build/debug/src/routing/global-routing/global-router-interface_1.o [546/905] > cxx: src/routing/global-routing/global-route-manager.cc -> > build/debug/src/routing/global-routing/global-route-manager_1.o [547/905] > cxx: src/routing/global-routing/global-route-manager-impl.cc -> > build/debug/src/routing/global-routing/global-route-manager-impl_1.o > [548/905] cxx: src/routing/global-routing/candidate-queue.cc -> > build/debug/src/routing/global-routing/candidate-queue_1.o [549/905] cxx: > src/routing/global-routing/ipv4-global-routing.cc -> > build/debug/src/routing/global-routing/ipv4-global-routing_1.o [550/905] > cxx: src/routing/static-routing/ipv4-static-routing.cc -> > build/debug/src/routing/static-routing/ipv4-static-routing_1.o [551/905] > cxx: src/routing/static-routing/ipv4-routing-table-entry.cc -> > build/debug/src/routing/static-routing/ipv4-routing-table-entry_1.o > [552/905] cxx: src/routing/static-routing/ipv6-static-routing.cc -> > build/debug/src/routing/static-routing/ipv6-static-routing_1.o [553/905] > cxx: src/routing/static-routing/ipv6-routing-table-entry.cc -> > build/debug/src/routing/static-routing/ipv6-routing-table-entry_1.o > [554/905] cxx: src/routing/list-routing/ipv4-list-routing.cc -> > build/debug/src/routing/list-routing/ipv4-list-routing_1.o [555/905] cxx: > src/routing/list-routing/ipv6-list-routing.cc -> > build/debug/src/routing/list-routing/ipv6-list-routing_1.o [556/905] cxx: > src/mobility/hierarchical-mobility-model.cc -> > build/debug/src/mobility/hierarchical-mobility-model_1.o [557/905] cxx: > src/mobility/mobility-model.cc -> > build/debug/src/mobility/mobility-model_1.o [558/905] cxx: > src/mobility/position-allocator.cc -> > build/debug/src/mobility/position-allocator_1.o [559/905] cxx: > src/mobility/rectangle.cc -> build/debug/src/mobility/rectangle_1.o > [560/905] cxx: src/mobility/constant-position-mobility-model.cc -> > build/debug/src/mobility/constant-position-mobility-model_1.o [561/905] cxx: > src/mobility/constant-velocity-helper.cc -> > build/debug/src/mobility/constant-velocity-helper_1.o [562/905] cxx: > src/mobility/constant-velocity-mobility-model.cc -> > build/debug/src/mobility/constant-velocity-mobility-model_1.o [563/905] cxx: > src/mobility/random-waypoint-mobility-model.cc -> > build/debug/src/mobility/random-waypoint-mobility-model_1.o [564/905] cxx: > src/mobility/random-walk-2d-mobility-model.cc -> > build/debug/src/mobility/random-walk-2d-mobility-model_1.o [565/905] cxx: > src/mobility/random-direction-2d-mobility-model.cc -> > build/debug/src/mobility/random-direction-2d-mobility-model_1.o [566/905] > cxx: src/mobility/constant-acceleration-mobility-model.cc -> > build/debug/src/mobility/constant-acceleration-mobility-model_1.o [567/905] > cxx: src/devices/wifi/propagation-delay-model.cc -> > build/debug/src/devices/wifi/propagation-delay-model_1.o [568/905] cxx: > src/devices/wifi/propagation-loss-model.cc -> > build/debug/src/devices/wifi/propagation-loss-model_1.o [569/905] cxx: > src/devices/wifi/jakes-propagation-loss-model.cc -> > build/debug/src/devices/wifi/jakes-propagation-loss-model_1.o [570/905] cxx: > src/devices/wifi/wifi-channel.cc -> > build/debug/src/devices/wifi/wifi-channel_1.o [571/905] cxx: > src/devices/wifi/wifi-mode.cc -> build/debug/src/devices/wifi/wifi-mode_1.o > [572/905] cxx: src/devices/wifi/ssid.cc -> > build/debug/src/devices/wifi/ssid_1.o [573/905] cxx: > src/devices/wifi/wifi-phy.cc -> build/debug/src/devices/wifi/wifi-phy_1.o > [574/905] cxx: src/devices/wifi/wifi-phy-state-helper.cc -> > build/debug/src/devices/wifi/wifi-phy-state-helper_1.o [575/905] cxx: > src/devices/wifi/error-rate-model.cc -> > build/debug/src/devices/wifi/error-rate-model_1.o [576/905] cxx: > src/devices/wifi/yans-error-rate-model.cc -> > build/debug/src/devices/wifi/yans-error-rate-model_1.o [577/905] cxx: > src/devices/wifi/interference-helper.cc -> > build/debug/src/devices/wifi/interference-helper_1.o [578/905] cxx: > src/devices/wifi/interference-helper-tx-duration-test.cc -> > build/debug/src/devices/wifi/interference-helper-tx-duration-test_1.o > [579/905] cxx: src/devices/wifi/yans-wifi-phy.cc -> > build/debug/src/devices/wifi/yans-wifi-phy_1.o [580/905] cxx: > src/devices/wifi/yans-wifi-channel.cc -> > build/debug/src/devices/wifi/yans-wifi-channel_1.o [581/905] cxx: > src/devices/wifi/wifi-mac-header.cc -> > build/debug/src/devices/wifi/wifi-mac-header_1.o [582/905] cxx: > src/devices/wifi/wifi-mac-trailer.cc -> > build/debug/src/devices/wifi/wifi-mac-trailer_1.o [583/905] cxx: > src/devices/wifi/mac-low.cc -> build/debug/src/devices/wifi/mac-low_1.o > [584/905] cxx: src/devices/wifi/wifi-mac-queue.cc -> > build/debug/src/devices/wifi/wifi-mac-queue_1.o [585/905] cxx: > src/devices/wifi/mac-tx-middle.cc -> > build/debug/src/devices/wifi/mac-tx-middle_1.o [586/905] cxx: > src/devices/wifi/mac-rx-middle.cc -> > build/debug/src/devices/wifi/mac-rx-middle_1.o [587/905] cxx: > src/devices/wifi/dca-txop.cc -> build/debug/src/devices/wifi/dca-txop_1.o > [588/905] cxx: src/devices/wifi/supported-rates.cc -> > build/debug/src/devices/wifi/supported-rates_1.o [589/905] cxx: > src/devices/wifi/capability-information.cc -> > build/debug/src/devices/wifi/capability-information_1.o [590/905] cxx: > src/devices/wifi/status-code.cc -> > build/debug/src/devices/wifi/status-code_1.o [591/905] cxx: > src/devices/wifi/mgt-headers.cc -> > build/debug/src/devices/wifi/mgt-headers_1.o [592/905] cxx: > src/devices/wifi/random-stream.cc -> > build/debug/src/devices/wifi/random-stream_1.o [593/905] cxx: > src/devices/wifi/dcf-manager.cc -> > build/debug/src/devices/wifi/dcf-manager_1.o [594/905] cxx: > src/devices/wifi/dcf-manager-test.cc -> > build/debug/src/devices/wifi/dcf-manager-test_1.o [595/905] cxx: > src/devices/wifi/wifi-mac.cc -> build/debug/src/devices/wifi/wifi-mac_1.o > [596/905] cxx: src/devices/wifi/wifi-remote-station-manager.cc -> > build/debug/src/devices/wifi/wifi-remote-station-manager_1.o [597/905] cxx: > src/devices/wifi/adhoc-wifi-mac.cc -> > build/debug/src/devices/wifi/adhoc-wifi-mac_1.o [598/905] cxx: > src/devices/wifi/nqap-wifi-mac.cc -> > build/debug/src/devices/wifi/nqap-wifi-mac_1.o [599/905] cxx: > src/devices/wifi/nqsta-wifi-mac.cc -> > build/debug/src/devices/wifi/nqsta-wifi-mac_1.o [600/905] cxx: > src/devices/wifi/wifi-net-device.cc -> > build/debug/src/devices/wifi/wifi-net-device_1.o [601/905] cxx: > src/devices/wifi/arf-wifi-manager.cc -> > build/debug/src/devices/wifi/arf-wifi-manager_1.o [602/905] cxx: > src/devices/wifi/aarf-wifi-manager.cc -> > build/debug/src/devices/wifi/aarf-wifi-manager_1.o [603/905] cxx: > src/devices/wifi/ideal-wifi-manager.cc -> > build/debug/src/devices/wifi/ideal-wifi-manager_1.o [604/905] cxx: > src/devices/wifi/amrr-wifi-manager.cc -> > build/debug/src/devices/wifi/amrr-wifi-manager_1.o [605/905] cxx: > src/devices/wifi/onoe-wifi-manager.cc -> > build/debug/src/devices/wifi/onoe-wifi-manager_1.o [606/905] cxx: > src/devices/wifi/rraa-wifi-manager.cc -> > build/debug/src/devices/wifi/rraa-wifi-manager_1.o [607/905] cxx: > src/devices/wifi/aarfcd-wifi-manager.cc -> > build/debug/src/devices/wifi/aarfcd-wifi-manager_1.o [608/905] cxx: > src/devices/wifi/cara-wifi-manager.cc -> > build/debug/src/devices/wifi/cara-wifi-manager_1.o [609/905] cxx: > src/devices/wifi/constant-rate-wifi-manager.cc -> > build/debug/src/devices/wifi/constant-rate-wifi-manager_1.o [610/905] cxx: > src/devices/wifi/wifi-test.cc -> build/debug/src/devices/wifi/wifi-test_1.o > [611/905] cxx: src/devices/wifi/qos-tag.cc -> > build/debug/src/devices/wifi/qos-tag_1.o [612/905] cxx: > src/devices/wifi/qos-utils.cc -> build/debug/src/devices/wifi/qos-utils_1.o > [613/905] cxx: src/devices/wifi/qadhoc-wifi-mac.cc -> > build/debug/src/devices/wifi/qadhoc-wifi-mac_1.o [614/905] cxx: > src/devices/wifi/qap-wifi-mac.cc -> > build/debug/src/devices/wifi/qap-wifi-mac_1.o [615/905] cxx: > src/devices/wifi/qsta-wifi-mac.cc -> > build/debug/src/devices/wifi/qsta-wifi-mac_1.o [616/905] cxx: > src/devices/wifi/edca-txop-n.cc -> > build/debug/src/devices/wifi/edca-txop-n_1.o [617/905] cxx: > src/devices/wifi/msdu-aggregator.cc -> > build/debug/src/devices/wifi/msdu-aggregator_1.o [618/905] cxx: > src/devices/wifi/amsdu-subframe-header.cc -> > build/debug/src/devices/wifi/amsdu-subframe-header_1.o [619/905] cxx: > src/devices/wifi/msdu-standard-aggregator.cc -> > build/debug/src/devices/wifi/msdu-standard-aggregator_1.o [620/905] cxx: > src/devices/wifi/minstrel-wifi-manager.cc -> > build/debug/src/devices/wifi/minstrel-wifi-manager_1.o [621/905] cxx: > src/devices/wifi/dcf.cc -> build/debug/src/devices/wifi/dcf_1.o [622/905] > cxx: src/devices/wifi/wifi-phy-test.cc -> > build/debug/src/devices/wifi/wifi-phy-test_3.o [623/905] cxx: > src/helper/node-container.cc -> build/debug/src/helper/node-container_1.o > [624/905] cxx: src/helper/net-device-container.cc -> > build/debug/src/helper/net-device-container_1.o [625/905] cxx: > src/helper/wifi-helper.cc -> build/debug/src/helper/wifi-helper_1.o > [626/905] cxx: src/helper/olsr-helper.cc -> > build/debug/src/helper/olsr-helper_1.o [627/905] cxx: > src/helper/point-to-point-helper.cc -> > build/debug/src/helper/point-to-point-helper_1.o [628/905] cxx: > src/helper/csma-helper.cc -> build/debug/src/helper/csma-helper_1.o > [629/905] cxx: src/helper/mobility-helper.cc -> > build/debug/src/helper/mobility-helper_1.o [630/905] cxx: > src/helper/ns2-mobility-helper.cc -> > build/debug/src/helper/ns2-mobility-helper_1.o [631/905] cxx: > src/helper/ipv4-address-helper.cc -> > build/debug/src/helper/ipv4-address-helper_1.o [632/905] cxx: > src/helper/ipv4-static-routing-helper.cc -> > build/debug/src/helper/ipv4-static-routing-helper_1.o [633/905] cxx: > src/helper/internet-stack-helper.cc -> > build/debug/src/helper/internet-stack-helper_1.o [634/905] cxx: > src/helper/application-container.cc -> > build/debug/src/helper/application-container_1.o [635/905] cxx: > src/helper/on-off-helper.cc -> build/debug/src/helper/on-off-helper_1.o > [636/905] cxx: src/helper/packet-sink-helper.cc -> > build/debug/src/helper/packet-sink-helper_1.o [637/905] cxx: > src/helper/packet-socket-helper.cc -> > build/debug/src/helper/packet-socket-helper_1.o [638/905] cxx: > src/helper/ipv4-interface-container.cc -> > build/debug/src/helper/ipv4-interface-container_1.o [639/905] cxx: > src/helper/udp-echo-helper.cc -> build/debug/src/helper/udp-echo-helper_1.o > [640/905] cxx: src/helper/bridge-helper.cc -> > build/debug/src/helper/bridge-helper_1.o [641/905] cxx: > src/helper/yans-wifi-helper.cc -> > build/debug/src/helper/yans-wifi-helper_1.o [642/905] cxx: > src/helper/v4ping-helper.cc -> build/debug/src/helper/v4ping-helper_1.o > [643/905] cxx: src/helper/nqos-wifi-mac-helper.cc -> > build/debug/src/helper/nqos-wifi-mac-helper_1.o [644/905] cxx: > src/helper/qos-wifi-mac-helper.cc -> > build/debug/src/helper/qos-wifi-mac-helper_1.o [645/905] cxx: > src/helper/ipv4-nix-vector-helper.cc -> > build/debug/src/helper/ipv4-nix-vector-helper_1.o [646/905] cxx: > src/helper/ipv4-global-routing-helper.cc -> > build/debug/src/helper/ipv4-global-routing-helper_1.o [647/905] cxx: > src/helper/ipv4-list-routing-helper.cc -> > build/debug/src/helper/ipv4-list-routing-helper_1.o [648/905] cxx: > src/helper/ipv4-routing-helper.cc -> > build/debug/src/helper/ipv4-routing-helper_1.o [649/905] cxx: > src/helper/mesh-helper.cc -> build/debug/src/helper/mesh-helper_1.o > [650/905] cxx: src/helper/dot11s-installer.cc -> > build/debug/src/helper/dot11s-installer_1.o [651/905] cxx: > src/helper/flame-installer.cc -> build/debug/src/helper/flame-installer_1.o > [652/905] cxx: src/helper/athstats-helper.cc -> > build/debug/src/helper/athstats-helper_1.o [653/905] cxx: > src/helper/ipv6-address-helper.cc -> > build/debug/src/helper/ipv6-address-helper_1.o [654/905] cxx: > src/helper/ipv6-interface-container.cc -> > build/debug/src/helper/ipv6-interface-container_1.o [655/905] cxx: > src/helper/ipv6-static-routing-helper.cc -> > build/debug/src/helper/ipv6-static-routing-helper_1.o [656/905] cxx: > src/helper/ipv6-list-routing-helper.cc -> > build/debug/src/helper/ipv6-list-routing-helper_1.o [657/905] cxx: > src/helper/ipv6-routing-helper.cc -> > build/debug/src/helper/ipv6-routing-helper_1.o [658/905] cxx: > src/helper/ping6-helper.cc -> build/debug/src/helper/ping6-helper_1.o > [659/905] cxx: src/helper/flow-monitor-helper.cc -> > build/debug/src/helper/flow-monitor-helper_1.o [660/905] cxx: > src/helper/emu-helper.cc -> build/debug/src/helper/emu-helper_1.o [661/905] > cxx: src/helper/tap-bridge-helper.cc -> > build/debug/src/helper/tap-bridge-helper_1.o [662/905] cxx: > src/contrib/stats/data-calculator.cc -> > build/debug/src/contrib/stats/data-calculator_1.o [663/905] cxx: > src/contrib/stats/packet-data-calculators.cc -> > build/debug/src/contrib/stats/packet-data-calculators_1.o [664/905] cxx: > src/contrib/stats/time-data-calculators.cc -> > build/debug/src/contrib/stats/time-data-calculators_1.o [665/905] cxx: > src/contrib/stats/data-output-interface.cc -> > build/debug/src/contrib/stats/data-output-interface_1.o [666/905] cxx: > src/contrib/stats/omnet-data-output.cc -> > build/debug/src/contrib/stats/omnet-data-output_1.o [667/905] cxx: > src/contrib/stats/data-collector.cc -> > build/debug/src/contrib/stats/data-collector_1.o [668/905] cxx: > src/applications/v4ping/v4ping.cc -> > build/debug/src/applications/v4ping/v4ping_1.o [669/905] cxx: > src/devices/mesh/wifi-information-element-vector.cc -> > build/debug/src/devices/mesh/wifi-information-element-vector_1.o [670/905] > cxx: src/devices/mesh/mesh-point-device.cc -> > build/debug/src/devices/mesh/mesh-point-device_1.o [671/905] cxx: > src/devices/mesh/mesh-l2-routing-protocol.cc -> > build/debug/src/devices/mesh/mesh-l2-routing-protocol_1.o [672/905] cxx: > src/devices/mesh/mesh-wifi-beacon.cc -> > build/debug/src/devices/mesh/mesh-wifi-beacon_1.o [673/905] cxx: > src/devices/mesh/mesh-wifi-interface-mac.cc -> > build/debug/src/devices/mesh/mesh-wifi-interface-mac_1.o [674/905] cxx: > src/devices/mesh/dot11s/ie-dot11s-beacon-timing.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-beacon-timing_1.o [675/905] > cxx: src/devices/mesh/dot11s/ie-dot11s-configuration.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-configuration_1.o [676/905] > cxx: src/devices/mesh/dot11s/ie-dot11s-id.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-id_1.o [677/905] cxx: > src/devices/mesh/dot11s/ie-dot11s-peer-management.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-peer-management_1.o [678/905] > cxx: src/devices/mesh/dot11s/ie-dot11s-preq.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-preq_1.o [679/905] cxx: > src/devices/mesh/dot11s/ie-dot11s-prep.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-prep_1.o [680/905] cxx: > src/devices/mesh/dot11s/ie-dot11s-perr.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-perr_1.o [681/905] cxx: > src/devices/mesh/dot11s/ie-dot11s-rann.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-rann_1.o [682/905] cxx: > src/devices/mesh/dot11s/ie-dot11s-peering-protocol.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-peering-protocol_1.o [683/905] > cxx: src/devices/mesh/dot11s/ie-dot11s-metric-report.cc -> > build/debug/src/devices/mesh/dot11s/ie-dot11s-metric-report_1.o [684/905] > cxx: src/devices/mesh/dot11s/dot11s-mac-header.cc -> > build/debug/src/devices/mesh/dot11s/dot11s-mac-header_1.o [685/905] cxx: > src/devices/mesh/dot11s/peer-link-frame.cc -> > build/debug/src/devices/mesh/dot11s/peer-link-frame_1.o [686/905] cxx: > src/devices/mesh/dot11s/peer-link.cc -> > build/debug/src/devices/mesh/dot11s/peer-link_1.o [687/905] cxx: > src/devices/mesh/dot11s/peer-management-protocol-mac.cc -> > build/debug/src/devices/mesh/dot11s/peer-management-protocol-mac_1.o > [688/905] cxx: src/devices/mesh/dot11s/peer-management-protocol.cc -> > build/debug/src/devices/mesh/dot11s/peer-management-protocol_1.o [689/905] > cxx: src/devices/mesh/dot11s/hwmp-tag.cc -> > build/debug/src/devices/mesh/dot11s/hwmp-tag_1.o [690/905] cxx: > src/devices/mesh/dot11s/hwmp-rtable.cc -> > build/debug/src/devices/mesh/dot11s/hwmp-rtable_1.o [691/905] cxx: > src/devices/mesh/dot11s/hwmp-protocol-mac.cc -> > build/debug/src/devices/mesh/dot11s/hwmp-protocol-mac_1.o [692/905] cxx: > src/devices/mesh/dot11s/hwmp-protocol.cc -> > build/debug/src/devices/mesh/dot11s/hwmp-protocol_1.o [693/905] cxx: > src/devices/mesh/dot11s/airtime-metric.cc -> > build/debug/src/devices/mesh/dot11s/airtime-metric_1.o [694/905] cxx: > src/devices/mesh/flame/flame-header.cc -> > build/debug/src/devices/mesh/flame/flame-header_1.o [695/905] cxx: > src/devices/mesh/flame/flame-rtable.cc -> > build/debug/src/devices/mesh/flame/flame-rtable_1.o [696/905] cxx: > src/devices/mesh/flame/flame-protocol-mac.cc -> > build/debug/src/devices/mesh/flame/flame-protocol-mac_1.o [697/905] cxx: > src/devices/mesh/flame/flame-protocol.cc -> > build/debug/src/devices/mesh/flame/flame-protocol_1.o [698/905] cxx: > src/applications/ping6/ping6.cc -> > build/debug/src/applications/ping6/ping6_1.o [699/905] cxx: > src/applications/radvd/radvd.cc -> > build/debug/src/applications/radvd/radvd_1.o [700/905] cxx: > src/applications/radvd/radvd-interface.cc -> > build/debug/src/applications/radvd/radvd-interface_1.o [701/905] cxx: > src/applications/radvd/radvd-prefix.cc -> > build/debug/src/applications/radvd/radvd-prefix_1.o [702/905] cxx: > src/test/ns3tcp/ns3tcp-interop-test-suite.cc -> > build/debug/src/test/ns3tcp/ns3tcp-interop-test-suite_1.o [703/905] cxx: > src/test/ns3tcp/ns3tcp-cwnd-test-suite.cc -> > build/debug/src/test/ns3tcp/ns3tcp-cwnd-test-suite_1.o [704/905] cxx: > src/test/ns3wifi/propagation-loss-models-test-suite.cc -> > build/debug/src/test/ns3wifi/propagation-loss-models-test-suite_1.o > [705/905] cxx: src/contrib/flow-monitor/flow-monitor.cc -> > build/debug/src/contrib/flow-monitor/flow-monitor_1.o [706/905] cxx: > src/contrib/flow-monitor/flow-classifier.cc -> > build/debug/src/contrib/flow-monitor/flow-classifier_1.o [707/905] cxx: > src/contrib/flow-monitor/flow-probe.cc -> > build/debug/src/contrib/flow-monitor/flow-probe_1.o [708/905] cxx: > src/contrib/flow-monitor/ipv4-flow-classifier.cc -> > build/debug/src/contrib/flow-monitor/ipv4-flow-classifier_1.o [709/905] cxx: > src/contrib/flow-monitor/ipv4-flow-probe.cc -> > build/debug/src/contrib/flow-monitor/ipv4-flow-probe_1.o [710/905] cxx: > src/contrib/flow-monitor/histogram.cc -> > build/debug/src/contrib/flow-monitor/histogram_1.o [711/905] cxx: > src/contrib/net-anim/point-to-point-dumbbell-helper.cc -> > build/debug/src/contrib/net-anim/point-to-point-dumbbell-helper_1.o > [712/905] cxx: src/contrib/net-anim/point-to-point-grid-helper.cc -> > build/debug/src/contrib/net-anim/point-to-point-grid-helper_1.o [713/905] > cxx: src/contrib/net-anim/animation-interface.cc -> > build/debug/src/contrib/net-anim/animation-interface_1.o [714/905] cxx: > src/contrib/net-anim/node-location.cc -> > build/debug/src/contrib/net-anim/node-location_1.o [715/905] cxx: > src/contrib/net-anim/test-dumbbell.cc -> > build/debug/src/contrib/net-anim/test-dumbbell_3.o [716/905] cxx: > src/contrib/net-anim/test-grid.cc -> > build/debug/src/contrib/net-anim/test-grid_4.o [717/905] cxx: > samples/main-attribute-value.cc -> > build/debug/samples/main-attribute-value_1.o [718/905] cxx: > samples/main-callback.cc -> build/debug/samples/main-callback_2.o [719/905] > cxx: samples/main-simulator.cc -> build/debug/samples/main-simulator_3.o > [720/905] cxx: samples/main-ptr.cc -> build/debug/samples/main-ptr_4.o > [721/905] cxx: samples/main-random-variable.cc -> > build/debug/samples/main-random-variable_5.o [722/905] cxx: > samples/main-packet-header.cc -> build/debug/samples/main-packet-header_6.o > [723/905] cxx: samples/main-packet-tag.cc -> > build/debug/samples/main-packet-tag_7.o [724/905] cxx: samples/main-test.cc > -> build/debug/samples/main-test_8.o [725/905] cxx: > samples/main-test-sync.cc -> build/debug/samples/main-test-sync_9.o > [726/905] cxx: samples/main-simple.cc -> > build/debug/samples/main-simple_10.o [727/905] cxx: > samples/main-grid-topology.cc -> build/debug/samples/main-grid-topology_11.o > [728/905] cxx: samples/main-random-topology.cc -> > build/debug/samples/main-random-topology_12.o [729/905] cxx: > samples/main-random-walk.cc -> build/debug/samples/main-random-walk_13.o > [730/905] cxx: samples/main-propagation-loss.cc -> > build/debug/samples/main-propagation-loss_14.o [731/905] cxx: > samples/main-ns2-mob.cc -> build/debug/samples/main-ns2-mob_15.o [732/905] > cxx: utils/run-tests.cc -> build/debug/utils/run-tests_1.o [733/905] cxx: > utils/test-runner.cc -> build/debug/utils/test-runner_2.o [734/905] cxx: > utils/bench-simulator.cc -> build/debug/utils/bench-simulator_3.o [735/905] > cxx: utils/bench-packets.cc -> build/debug/utils/bench-packets_4.o [736/905] > cxx: utils/print-introspected-doxygen.cc -> > build/debug/utils/print-introspected-doxygen_5.o [737/905] cxx: > examples/hello-simulator.cc -> build/debug/examples/hello-simulator_1.o > [738/905] cxx: examples/first.cc -> build/debug/examples/first_2.o [739/905] > cxx: examples/second.cc -> build/debug/examples/second_3.o [740/905] cxx: > examples/third.cc -> build/debug/examples/third_4.o [741/905] cxx: > examples/object-names.cc -> build/debug/examples/object-names_5.o [742/905] > cxx: examples/mixed-wireless.cc -> build/debug/examples/mixed-wireless_6.o > [743/905] cxx: examples/dynamic-global-routing.cc -> > build/debug/examples/dynamic-global-routing_7.o [744/905] cxx: > examples/static-routing-slash32.cc -> > build/debug/examples/static-routing-slash32_8.o [745/905] cxx: > examples/global-routing-slash32.cc -> > build/debug/examples/global-routing-slash32_9.o [746/905] cxx: > examples/global-injection-slash32.cc -> > build/debug/examples/global-injection-slash32_10.o [747/905] cxx: > examples/simple-global-routing.cc -> > build/debug/examples/simple-global-routing_11.o [748/905] cxx: > examples/virtual-net-device.cc -> > build/debug/examples/virtual-net-device_12.o [749/905] cxx: > examples/simple-alternate-routing.cc -> > build/debug/examples/simple-alternate-routing_13.o [750/905] cxx: > examples/simple-error-model.cc -> > build/debug/examples/simple-error-model_14.o [751/905] cxx: > examples/csma-one-subnet.cc -> build/debug/examples/csma-one-subnet_15.o > [752/905] cxx: examples/csma-bridge.cc -> > build/debug/examples/csma-bridge_16.o [753/905] cxx: > examples/csma-bridge-one-hop.cc -> > build/debug/examples/csma-bridge-one-hop_17.o [754/905] cxx: > examples/udp-echo.cc -> build/debug/examples/udp-echo_18.o [755/905] cxx: > examples/realtime-udp-echo.cc -> build/debug/examples/realtime-udp-echo_19.o > [756/905] cxx: examples/csma-broadcast.cc -> > build/debug/examples/csma-broadcast_20.o [757/905] cxx: > examples/csma-packet-socket.cc -> > build/debug/examples/csma-packet-socket_21.o [758/905] cxx: > examples/csma-multicast.cc -> build/debug/examples/csma-multicast_22.o > [759/905] cxx: examples/mixed-global-routing.cc -> > build/debug/examples/mixed-global-routing_23.o [760/905] cxx: > examples/simple-point-to-point-olsr.cc -> > build/debug/examples/simple-point-to-point-olsr_24.o [761/905] cxx: > examples/nix-simple.cc -> build/debug/examples/nix-simple_25.o [762/905] > cxx: examples/nms-p2p-nix.cc -> build/debug/examples/nms-p2p-nix_26.o > [763/905] cxx: examples/tcp-large-transfer.cc -> > build/debug/examples/tcp-large-transfer_27.o [764/905] cxx: > examples/tcp-nsc-lfn.cc -> build/debug/examples/tcp-nsc-lfn_28.o [765/905] > cxx: examples/tcp-nsc-zoo.cc -> build/debug/examples/tcp-nsc-zoo_29.o > [766/905] cxx: examples/tcp-star-server.cc -> > build/debug/examples/tcp-star-server_30.o [767/905] cxx: examples/star.cc -> > build/debug/examples/star_31.o [768/905] cxx: examples/csma-star.cc -> > build/debug/examples/csma-star_32.o [769/905] cxx: examples/wifi-adhoc.cc -> > build/debug/examples/wifi-adhoc_33.o [770/905] cxx: > examples/wifi-clear-channel-cmu.cc -> > build/debug/examples/wifi-clear-channel-cmu_34.o [771/905] cxx: > examples/wifi-ap.cc -> build/debug/examples/wifi-ap_35.o [772/905] cxx: > examples/mesh.cc -> build/debug/examples/mesh_36.o [773/905] cxx: > examples/stats/wifi-example-sim.cc -> > build/debug/examples/stats/wifi-example-sim_1.o [774/905] cxx: > examples/stats/wifi-example-apps.cc -> > build/debug/examples/stats/wifi-example-apps_1.o [775/905] cxx: > examples/wifi-wired-bridging.cc -> > build/debug/examples/wifi-wired-bridging_37.o [776/905] cxx: > examples/csma-raw-ip-socket.cc -> > build/debug/examples/csma-raw-ip-socket_38.o [777/905] cxx: > examples/csma-ping.cc -> build/debug/examples/csma-ping_39.o [778/905] cxx: > examples/test-ipv6.cc -> build/debug/examples/test-ipv6_40.o [779/905] cxx: > examples/ping6.cc -> build/debug/examples/ping6_41.o [780/905] cxx: > examples/simple-routing-ping6.cc -> > build/debug/examples/simple-routing-ping6_42.o [781/905] cxx: > examples/icmpv6-redirect.cc -> build/debug/examples/icmpv6-redirect_43.o > [782/905] cxx: examples/radvd.cc -> build/debug/examples/radvd_44.o > [783/905] cxx: examples/radvd-two-prefix.cc -> > build/debug/examples/radvd-two-prefix_45.o [784/905] cxx: > examples/emu-udp-echo.cc -> build/debug/examples/emu-udp-echo_46.o [785/905] > cxx: examples/emu-ping.cc -> build/debug/examples/emu-ping_47.o [786/905] > cxx: examples/tap-wifi-dumbbell.cc -> > build/debug/examples/tap-wifi-dumbbell_48.o [787/905] cxx: > examples/simple-wifi-frame-aggregation.cc -> > build/debug/examples/simple-wifi-frame-aggregation_49.o [788/905] cxx: > examples/multi-rate-first.cc -> build/debug/examples/multi-rate-first_50.o > [789/905] cxx: examples/multi-rate-second.cc -> > build/debug/examples/multi-rate-second_51.o [790/905] cxx: > scratch/multiple-sources/simple-main.cc -> > build/debug/scratch/multiple-sources/simple-main_1.o [791/905] cxx: > scratch/multiple-sources/simple-simulation.cc -> > build/debug/scratch/multiple-sources/simple-simulation_1.o [792/905] cxx: > scratch/simple.cc -> build/debug/scratch/simple_2.o [793/905] cxx: > build/debug/bindings/python/ns3module.cc -> > build/debug/bindings/python/ns3module_3.o [794/905] cxx: > bindings/python/ns3module_helpers.cc -> > build/debug/bindings/python/ns3module_helpers_3.o [795/905] cxx: > build/debug/bindings/python/ns3_module_emu.cc -> > build/debug/bindings/python/ns3_module_emu_3.o [796/905] cxx: > build/debug/bindings/python/ns3_module_flow_monitor.cc -> > build/debug/bindings/python/ns3_module_flow_monitor_3.o > debug/bindings/python/ns3_module_flow_monitor.cc: In function ?PyObject* > _wrap_PyNs3FlowProbeFlowStats__get_bytesDropped(PyNs3FlowProbeFlowStats*)?: > debug/bindings/python/ns3_module_flow_monitor.cc:749: error: no matching > function for call to ?std::vector >::vector(std::vector >&)? > /usr/include/c++/4.3/bits/stl_vector.h:247: note: candidates are: > std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp > = long unsigned int, _Alloc = std::allocator] > /usr/include/c++/4.3/bits/stl_vector.h:234: note: std::vector<_Tp, > _Alloc>::vector(size_t, const _Tp&, const _Alloc&) [with _Tp = long unsigned > int, _Alloc = std::allocator] /usr/include/c++/4.3/bits/stl_vector.h:221: > note: std::vector<_Tp, _Alloc>::vector(const _Alloc&) [with _Tp = long > unsigned int, _Alloc = std::allocator] > /usr/include/c++/4.3/bits/stl_vector.h:213: note: std::vector<_Tp, > _Alloc>::vector() [with _Tp = long unsigned int, _Alloc = std::allocator] > debug/bindings/python/ns3_module_flow_monitor.cc: In function ?PyObject* > _wrap_PyNs3FlowMonitorFlowStats__get_bytesDropped(PyNs3FlowMonitorFlowStats*)?: > debug/bindings/python/ns3_module_flow_monitor.cc:2675: error: no matching > function for call to ?std::vector >::vector(std::vector >&)? > /usr/include/c++/4.3/bits/stl_vector.h:247: note: candidates are: > std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp > = long unsigned int, _Alloc = std::allocator] > /usr/include/c++/4.3/bits/stl_vector.h:234: note: std::vector<_Tp, > _Alloc>::vector(size_t, const _Tp&, const _Alloc&) [with _Tp = long unsigned > int, _Alloc = std::allocator] /usr/include/c++/4.3/bits/stl_vector.h:221: > note: std::vector<_Tp, _Alloc>::vector(const _Alloc&) [with _Tp = long > unsigned int, _Alloc = std::allocator] > /usr/include/c++/4.3/bits/stl_vector.h:213: note: std::vector<_Tp, > _Alloc>::vector() [with _Tp = long unsigned int, _Alloc = std::allocator] > Waf: Leaving directory > `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build' Build failed -> > task failed (err #1): {task: cxx ns3_module_flow_monitor.cc -> > ns3_module_flow_monitor_3.o} ns3modulegen.log: ??:??: < ns3::Ptr< > ns3::RadvdPrefix > >'> / TypeLookupError(['ns3::Ptr< ns3::RadvdPrefix >', > 'ns3::RadvdPrefix *'],) ??:??: < ns3::Ptr< ns3::Packet > >'> / > TypeLookupError(['ns3::Ptr< ns3::Packet >', 'ns3::Packet *'],) ??:??: < > ns3::Ptr< ns3::FlowProbe > >'> / TypeLookupError(['ns3::Ptr< ns3::FlowProbe > >', 'ns3::FlowProbe *'],) ??:??: < ns3::Ptr< ns3::NetDevice > >'> / > TypeLookupError(['ns3::Ptr< ns3::NetDevice >', 'ns3::NetDevice *'],) > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/bindings/python/ns3modulegen_core_customizations.py:69: > DeprecationWarning: Typo: set_tranformation -> set_transformation > handler.set_tranformation(self, orig_ctype) ??:??: < ns3::Ptr< > ns3::dot11s::IeBeaconTimingUnit > >'> / TypeLookupError(['ns3::Ptr< > ns3::dot11s::IeBeaconTimingUnit >', 'ns3::dot11s::IeBeaconTimingUnit *'],) > ??:??: < ns3::olsr::MprSelectorTuple >'> / > TypeLookupError(['ns3::olsr::MprSelectorTuple'],) ??:??: < > ns3::olsr::NeighborTuple >'> / > TypeLookupError(['ns3::olsr::NeighborTuple'],) ??:??: < > ns3::olsr::TwoHopNeighborTuple >'> / > TypeLookupError(['ns3::olsr::TwoHopNeighborTuple'],) ??:??: < > ns3::olsr::LinkTuple >'> / TypeLookupError(['ns3::olsr::LinkTuple'],) ??:??: > < ns3::olsr::TopologyTuple >'> / > TypeLookupError(['ns3::olsr::TopologyTuple'],) ??:??: < > ns3::olsr::IfaceAssocTuple >'> / > TypeLookupError(['ns3::olsr::IfaceAssocTuple'],) ??:??: < std::pair< > ns3::Ptr< ns3::Packet >, ns3::AmsduSubframeHeader > >'> / > TypeLookupError(['std::pair< ns3::Ptr< ns3::Packet >, > ns3::AmsduSubframeHeader >'],) > /tmp/ns-commits/tests/tmp/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py:1044: > DeprecationWarning: is_const is deprecated, put a 'const' in the C type > instead. warnings.warn("is_const is deprecated, put a 'const' in the C type > instead.", DeprecationWarning) > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/bindings/python/ns3modulegen_core_customizations.py:206: > Warning: ***** Unable to register callback; Return value 'std::vector >' > error (used in ns3::Callback< std::vector >, unsigned int, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, > ns3::empty >): TypeLookupError(['std::vector< ns3::Mac48Address, > std::allocator< ns3::Mac48Address > >'],) Warning) > ../bindings/python/ns3_module_core.py:388: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_core.py:471: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::GlobalValue * const *, > std::vector< ns3::GlobalValue * > >'],) > ../bindings/python/ns3_module_core.py:486: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::GlobalValue * const *, > std::vector< ns3::GlobalValue * > >'],) > ../bindings/python/ns3_module_core.py:1008: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_core.py:1012: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_core.py:1083: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_core.py:1093: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_core.py:1106: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_core.py:1114: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_core.py:1142: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_core.py:1309: TypeLookupError(['ns3::Callback< > ns3::ObjectBase *, ns3::empty, ns3::empty, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_core.py:1383: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_core.py:1518: TypeLookupError(['long int'],) > ../bindings/python/ns3_module_core.py:2089: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_core.py:2123: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Object > > const, std::vector< ns3::Ptr< ns3::Object > > >'],) > ../bindings/python/ns3_module_core.py:2138: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Object > > const, std::vector< ns3::Ptr< ns3::Object > > >'],) > ../bindings/python/ns3_module_core.py:2453: TypeLookupError(['unsigned int > &'],) ../bindings/python/ns3_module_core.py:2486: TypeLookupError(['unsigned > int &'],) ../bindings/python/ns3_module_core.py:2500: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Object > > const, std::vector< ns3::Ptr< ns3::Object > > >'],) > ../bindings/python/ns3_module_core.py:2521: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Object > > const, std::vector< ns3::Ptr< ns3::Object > > >'],) > ../bindings/python/ns3_module_simulator.py:215: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_simulator.py:424: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_simulator.py:476: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_simulator.py:568: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_simulator.py:617: > TypeConfigurationError('caller_owns_return not given',) ??:??: None / > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_simulator.py:842: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:847: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:852: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1077: TypeLookupError(['timeval > *'],) ../bindings/python/ns3_module_simulator.py:1092: > TypeLookupError(['timeval *'],) > ../bindings/python/ns3_module_simulator.py:1097: TypeLookupError(['timeval > *'],) ../bindings/python/ns3_module_simulator.py:1206: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1211: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1216: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1461: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1466: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1471: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1475: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_simulator.py:1479: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_common.py:201: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_common.py:236: TypeLookupError(['uint8_t *'],) > ../bindings/python/ns3_module_common.py:299: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:343: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:538: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:579: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:584: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_common.py:633: TypeLookupError(['uint8_t *'],) > ??:??: None / TypeLookupError(['uint8_t [ 20 ]'],) ??:??: None / > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_common.py:937: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:941: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:984: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:992: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_common.py:1020: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:335: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:346: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:351: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:355: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:360: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:510: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:575: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:772: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:790: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:815: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:905: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:913: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:978: TypeConfigurationError('direction > not given',) ../bindings/python/ns3_module_node.py:991: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1053: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1058: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1124: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1129: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1151: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Node > const, > std::vector< ns3::Ptr< ns3::Node > > >'],) > ../bindings/python/ns3_module_node.py:1156: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Node > const, > std::vector< ns3::Ptr< ns3::Node > > >'],) > ../bindings/python/ns3_module_node.py:1237: > TypeLookupError(['std::_List_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1242: > TypeLookupError(['std::_List_const_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1255: > TypeLookupError(['std::_List_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1260: > TypeLookupError(['std::_List_const_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1264: > TypeLookupError(['std::_List_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1268: > TypeLookupError(['std::_List_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1277: > TypeLookupError(['std::_List_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1316: > TypeLookupError(['std::_List_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1321: > TypeLookupError(['std::_List_const_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1334: > TypeLookupError(['std::_List_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1339: > TypeLookupError(['std::_List_const_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1343: > TypeLookupError(['std::_List_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1347: > TypeLookupError(['std::_List_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1356: > TypeLookupError(['std::_List_iterator< unsigned char >'],) > ../bindings/python/ns3_module_node.py:1410: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1415: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbAddressTlv > > >'],) ../bindings/python/ns3_module_node.py:1428: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1433: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbAddressTlv > > >'],) ../bindings/python/ns3_module_node.py:1437: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1441: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1454: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1485: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1495: > TypeLookupError(['std::_List_const_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1500: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1512: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1522: > TypeLookupError(['std::_List_const_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1527: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1539: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1549: > TypeLookupError(['std::_List_const_iterator< ns3::Address >'],) > ../bindings/python/ns3_module_node.py:1554: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:1572: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1577: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbAddressTlv > > >'],) ../bindings/python/ns3_module_node.py:1594: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1599: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbAddressTlv > > >'],) ../bindings/python/ns3_module_node.py:1603: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1607: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1621: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressTlv > >'],) > ../bindings/python/ns3_module_node.py:1679: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressBlock > > >'],) ../bindings/python/ns3_module_node.py:1684: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbAddressBlock > > >'],) ../bindings/python/ns3_module_node.py:1697: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressBlock > > >'],) ../bindings/python/ns3_module_node.py:1702: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbAddressBlock > > >'],) ../bindings/python/ns3_module_node.py:1706: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressBlock > > >'],) ../bindings/python/ns3_module_node.py:1710: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbAddressBlock > > >'],) ../bindings/python/ns3_module_node.py:1852: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:1857: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:1870: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:1875: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:1879: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:1883: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2086: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:2149: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2154: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2171: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2176: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2180: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2184: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2198: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2968: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2972: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:2976: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbMessage > >'],) > ../bindings/python/ns3_module_node.py:2980: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbMessage > >'],) > ../bindings/python/ns3_module_node.py:3023: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbMessage > >'],) > ../bindings/python/ns3_module_node.py:3028: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbMessage > > >'],) ../bindings/python/ns3_module_node.py:3041: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbMessage > >'],) > ../bindings/python/ns3_module_node.py:3046: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbMessage > > >'],) ../bindings/python/ns3_module_node.py:3108: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:3113: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:3126: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:3131: > TypeLookupError(['std::_List_const_iterator< ns3::Ptr< ns3::PbbTlv > >'],) > ../bindings/python/ns3_module_node.py:3334: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:3347: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:3360: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:3369: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_node.py:4277: TypeLookupError(['ns3::Callback< > void, ns3::Ptr< ns3::Ipv4Route >, ns3::Ptr< ns3::Packet const >, > ns3::Ipv4Header const &, ns3::empty, ns3::empty, ns3::empty, ns3::empty, > ns3::empty, ns3::empty >'],) ../bindings/python/ns3_module_node.py:4470: > TypeLookupError(['ns3::Callback< void, ns3::Ptr< ns3::Ipv6Route >, ns3::Ptr< > ns3::Packet const >, ns3::Ipv6Header const &, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_contrib.py:277: > TypeLookupError(['ns3::GnuplotDataset::Data *'],) > ../bindings/python/ns3_module_internet_stack.py:220: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_internet_stack.py:289: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_internet_stack.py:417: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_internet_stack.py:1359: > TypeLookupError(['SequenceNumber'],) > ../bindings/python/ns3_module_internet_stack.py:1384: > TypeLookupError(['SequenceNumber'],) > ../bindings/python/ns3_module_internet_stack.py:1432: > TypeLookupError(['SequenceNumber'],) > ../bindings/python/ns3_module_internet_stack.py:1448: > TypeLookupError(['SequenceNumber'],) > ../bindings/python/ns3_module_internet_stack.py:1537: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_internet_stack.py:1561: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:1575: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_internet_stack.py:1591: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:1611: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:1695: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:1703: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:1885: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2012: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2017: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_internet_stack.py:2086: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2226: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2231: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_internet_stack.py:2240: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_internet_stack.py:2254: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2267: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_internet_stack.py:2271: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:2275: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2293: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:2382: > TypeLookupError(['std::list< ns3::Ptr< ns3::Packet > >'],) > ../bindings/python/ns3_module_internet_stack.py:2390: > TypeLookupError(['std::list< ns3::Ptr< ns3::Packet > >'],) > ../bindings/python/ns3_module_internet_stack.py:2475: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2479: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2483: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2487: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2491: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2495: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2504: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2525: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2529: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2533: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2537: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2541: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2549: > TypeLookupError(['ns3::Ipv4EndPoint *'],) > ../bindings/python/ns3_module_internet_stack.py:2564: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2569: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_internet_stack.py:2620: > TypeLookupError(['ns3::Ptr< ns3::Ipv4Interface >', 'ns3::Ipv4Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2659: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2663: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2667: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2675: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:2688: > TypeLookupError(['ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2717: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:2721: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_internet_stack.py:2731: > TypeLookupError(['ns3::Ptr< ns3::Ipv6Interface >', 'ns3::Ipv6Interface *'],) > ../bindings/python/ns3_module_internet_stack.py:2763: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_csma.py:439: TypeLookupError(['uint16_t &'],) > ../bindings/python/ns3_module_wifi.py:385: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:442: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:547: TypeLookupError(['ns3::Ptr< > ns3::InterferenceHelper::Event >', 'ns3::InterferenceHelper::Event *'],) > ../bindings/python/ns3_module_wifi.py:551: TypeLookupError(['ns3::Ptr< > ns3::InterferenceHelper::Event >', 'ns3::InterferenceHelper::Event *'],) > ../bindings/python/ns3_module_wifi.py:3065: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:3080: TypeLookupError(['ns3::Callback< > void, ns3::Ptr< ns3::Packet const >, double, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_wifi.py:3085: TypeLookupError(['ns3::Callback< > void, ns3::Ptr< ns3::Packet >, double, ns3::WifiMode, ns3::WifiPreamble, > ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_wifi.py:3101: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::WifiMode const *, > std::vector< ns3::WifiMode > >'],) > ../bindings/python/ns3_module_wifi.py:3106: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::WifiMode const *, > std::vector< ns3::WifiMode > >'],) > ../bindings/python/ns3_module_wifi.py:3160: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3164: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3199: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3335: TypeLookupError(['ns3::Callback< > void, ns3::Ptr< ns3::Packet >, double, ns3::WifiMode, ns3::WifiPreamble, > ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_wifi.py:3340: TypeLookupError(['ns3::Callback< > void, ns3::Ptr< ns3::Packet const >, double, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_wifi.py:3350: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:3614: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3695: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3722: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3813: > TypeLookupError(['ns3::MacTxMiddle *'],) > ../bindings/python/ns3_module_wifi.py:3817: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:3972: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:3985: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:4111: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:4235: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:4279: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_wifi.py:4322: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:4339: TypeLookupError(['std::list< > std::pair< ns3::Ptr< ns3::Packet >, ns3::AmsduSubframeHeader > >'],) > ../bindings/python/ns3_module_wifi.py:4695: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:5190: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:5439: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_wifi.py:5457: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_static_routing.py:454: > TypeLookupError(['ns3::Callback< void, ns3::Ptr< ns3::Ipv4Route >, ns3::Ptr< > ns3::Packet const >, ns3::Ipv4Header const &, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_static_routing.py:594: > TypeLookupError(['ns3::Callback< void, ns3::Ptr< ns3::Ipv6Route >, ns3::Ptr< > ns3::Packet const >, ns3::Ipv6Header const &, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_global_routing.py:149: > TypeConfigurationError('transfer_ownership parameter missing',) > ../bindings/python/ns3_module_global_routing.py:177: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_global_routing.py:335: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_global_routing.py:383: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_global_routing.py:417: > TypeLookupError(['ns3::Callback< void, ns3::Ptr< ns3::Ipv4Route >, ns3::Ptr< > ns3::Packet const >, ns3::Ipv4Header const &, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_stats.py:224: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::DataCalculator > >'],) > ../bindings/python/ns3_module_stats.py:228: > TypeLookupError(['std::_List_iterator< ns3::Ptr< ns3::DataCalculator > >'],) > ../bindings/python/ns3_module_stats.py:261: > TypeLookupError(['std::_List_iterator< std::pair< std::basic_string< char, > std::char_traits< char >, std::allocator< char > >, std::basic_string< char, > std::char_traits< char >, std::allocator< char > > > >'],) > ../bindings/python/ns3_module_stats.py:265: > TypeLookupError(['std::_List_iterator< std::pair< std::basic_string< char, > std::char_traits< char >, std::allocator< char > >, std::basic_string< char, > std::char_traits< char >, std::allocator< char > > > >'],) > ../bindings/python/ns3_module_list_routing.py:105: TypeLookupError(['int16_t > &'],) ../bindings/python/ns3_module_list_routing.py:135: > TypeLookupError(['ns3::Callback< void, ns3::Ptr< ns3::Ipv4Route >, ns3::Ptr< > ns3::Packet const >, ns3::Ipv4Header const &, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_list_routing.py:172: TypeLookupError(['int16_t > &'],) ../bindings/python/ns3_module_list_routing.py:212: > TypeLookupError(['ns3::Callback< void, ns3::Ptr< ns3::Ipv6Route >, ns3::Ptr< > ns3::Packet const >, ns3::Ipv6Header const &, ns3::empty, ns3::empty, > ns3::empty, ns3::empty, ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_udp_echo.py:116: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_olsr.py:229: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:233: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:242: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:250: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:259: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:263: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:267: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:271: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:280: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:284: > TypeConfigurationError('caller_owns_return not given',) > ../bindings/python/ns3_module_olsr.py:289: > TypeLookupError(['ns3::olsr::IfaceAssocSet &'],) > ../bindings/python/ns3_module_olsr.py:293: > TypeLookupError(['ns3::olsr::IfaceAssocSet &'],) > ../bindings/python/ns3_module_olsr.py:298: > TypeLookupError(['ns3::olsr::LinkSet &'],) > ../bindings/python/ns3_module_olsr.py:303: > TypeLookupError(['ns3::olsr::MprSelectorSet &'],) > ../bindings/python/ns3_module_olsr.py:308: > TypeLookupError(['ns3::olsr::NeighborSet &'],) > ../bindings/python/ns3_module_olsr.py:312: > TypeLookupError(['ns3::olsr::NeighborSet &'],) > ../bindings/python/ns3_module_olsr.py:317: > TypeLookupError(['ns3::olsr::TopologySet &'],) > ../bindings/python/ns3_module_olsr.py:322: > TypeLookupError(['ns3::olsr::TwoHopNeighborSet &'],) > ../bindings/python/ns3_module_olsr.py:326: > TypeLookupError(['ns3::olsr::TwoHopNeighborSet &'],) > ../bindings/python/ns3_module_olsr.py:821: TypeLookupError(['ns3::Callback< > void, ns3::Ptr< ns3::Ipv4Route >, ns3::Ptr< ns3::Packet const >, > ns3::Ipv4Header const &, ns3::empty, ns3::empty, ns3::empty, ns3::empty, > ns3::empty, ns3::empty >'],) > ../bindings/python/ns3_module_flow_monitor.py:289: > TypeLookupError(['std::vector< ns3::Ptr< ns3::FlowProbe > >'],) > ../bindings/python/ns3_module_radvd.py:154: TypeLookupError(['std::list< > ns3::Ptr< ns3::RadvdPrefix > >'],) > ../bindings/python/ns3_module_mesh.py:201: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< > ns3::WifiInformationElement >, std::vector< ns3::Ptr< > ns3::WifiInformationElement > > >'],) > ../bindings/python/ns3_module_mesh.py:215: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< > ns3::WifiInformationElement >, std::vector< ns3::Ptr< > ns3::WifiInformationElement > > >'],) > ../bindings/python/ns3_module_mesh.py:271: TypeLookupError(['uint16_t &'],) > ../bindings/python/ns3_module_mesh.py:570: TypeLookupError(['std::vector< > ns3::Ptr< ns3::NetDevice > >'],) > ../bindings/python/ns3_module_helper.py:241: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Application > > const, std::vector< ns3::Ptr< ns3::Application > > >'],) > ../bindings/python/ns3_module_helper.py:246: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Application > > const, std::vector< ns3::Ptr< ns3::Application > > >'],) > ../bindings/python/ns3_module_helper.py:985: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::NetDevice > > const, std::vector< ns3::Ptr< ns3::NetDevice > > >'],) > ../bindings/python/ns3_module_helper.py:990: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::NetDevice > > const, std::vector< ns3::Ptr< ns3::NetDevice > > >'],) > ../bindings/python/ns3_module_helper.py:1036: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Node > const, > std::vector< ns3::Ptr< ns3::Node > > >'],) > ../bindings/python/ns3_module_helper.py:1045: > TypeLookupError(['__gnu_cxx::__normal_iterator< ns3::Ptr< ns3::Node > const, > std::vector< ns3::Ptr< ns3::Node > > >'],) > ../bindings/python/ns3_module_helper.py:1357: > TypeConfigurationError('direction not given',) > ../bindings/python/ns3_module_dot11s.py:203: TypeLookupError(['uint16_t > &'],) ../bindings/python/ns3_module_dot11s.py:221: > TypeLookupError(['ns3::Callback< std::vector< ns3::Mac48Address >, unsigned > int, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, > ns3::empty, ns3::empty >'],) ../bindings/python/ns3_module_dot11s.py:279: > TypeLookupError(['std::vector< ns3::Ptr< ns3::dot11s::IeBeaconTimingUnit > > >'],) ../bindings/python/ns3_module_dot11s.py:581: > TypeLookupError(['ns3::Callback< void, unsigned int, ns3::Mac48Address, > bool, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty > >'],) ../bindings/python/ns3_module_flame.py:111: TypeLookupError(['uint16_t > &'],) > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/bindings/python/ns3modulegen_core_customizations.py:437: > DeprecationWarning: add_constructor has changed API; see the API > documentation cls.add_constructor(CustomCp