From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 1 01:20:25 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 01 Sep 2008 04:20:25 -0400 Subject: [Ns-bugs] [Bug 301] Bogus IP header length generated using second.cc example script In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=301 ------- Comment #3 from turletti at sophia.inria.fr 2008-09-01 04:20 ------- No, actually wireshark 1.0.2 (on my MAC OSX 10.5.4) seems to identify the following protocols on IP frames: [ppp:ip:udp:redbackli:ip] and complains on the second IP header (Bogus IP header length)... I put a snapshot of the wireshark at http://planete.inria.fr/turletti/test/wireshark-0-0.png Cheers Thierry -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 1 15:26:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 01 Sep 2008 18:26:30 -0400 Subject: [Ns-bugs] [Bug 301] Bogus IP header length generated using second.cc example script In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=301 ------- Comment #4 from tomh at tomh.org 2008-09-01 18:26 ------- (In reply to comment #1) > Note that tcpdump can decode without problem this pcap file. wireshark pb only? > I looked at the octal dump of the trace and it looked OK to me. And on my version of wireshark, I could not reproduce. Googling on "Redback Lawful Intercept" suggests to me that it might be a Wireshark bug: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2376 I will mark it as invalid (Wireshark bug) if I am not able to reproduce on other machines and if there are no further comments this week. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 03:15:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 06:15:11 -0400 Subject: [Ns-bugs] [Bug 303] DataCalculator::GetKey triggers a PyBindGen bug In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=303 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Comment #2 from gjcarneiro at gmail.com 2008-09-02 06:15 ------- Nevermind, I fixed PyBindGen. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 08:57:12 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 11:57:12 -0400 Subject: [Ns-bugs] [Bug 303] DataCalculator::GetKey triggers a PyBindGen bug In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=303 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-02 11:57 ------- no, it's a bug. It makes no sense to have return value types be const -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 10:05:41 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 13:05:41 -0400 Subject: [Ns-bugs] [Bug 303] DataCalculator::GetKey triggers a PyBindGen bug In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=303 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-09-02 13:05 ------- changeset 55dedf98ad49 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 10:35:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 13:35:49 -0400 Subject: [Ns-bugs] [Bug 282] Ipv4L4Demux is useful ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=282 ------- Comment #2 from raj.b at gatech.edu 2008-09-02 13:35 ------- I am okay with this patch. I think we need to solicit some feedback from George, but I can't seem to add George as a CC... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 10:40:14 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 13:40:14 -0400 Subject: [Ns-bugs] [Bug 282] Ipv4L4Demux is useful ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=282 ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-02 13:40 ------- this is because george has no bugzilla account -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 11:26:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 14:26:30 -0400 Subject: [Ns-bugs] [Bug 274] bridge must detect compatibility of devices with bridging mode In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=274 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|point to point device cannot|bridge must detect |ignore from and to addresses|compatibility of devices | |with bridging mode ------- Comment #14 from mathieu.lacage at sophia.inria.fr 2008-09-02 14:26 ------- changing title to reflect actual bug content -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 11:27:35 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 14:27:35 -0400 Subject: [Ns-bugs] [Bug 274] bridge must detect compatibility of devices with bridging mode In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=274 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #15 from mathieu.lacage at sophia.inria.fr 2008-09-02 14:27 ------- changeset 4eb48239b4dc -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 12:12:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 15:12:11 -0400 Subject: [Ns-bugs] [Bug 304] New: wifi does not support bridging Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=304 Summary: wifi does not support bridging Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 12:15:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 15:15:42 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 12:26:00 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 15:26:00 -0400 Subject: [Ns-bugs] [Bug 282] Ipv4L4Demux is useful ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=282 ------- Comment #4 from raj.b at gatech.edu 2008-09-02 15:25 ------- (In reply to comment #2) > I am okay with this patch. I think we need to solicit some feedback from > George, but I can't seem to add George as a CC... > George has an account now, but that was another bug :-) After speaking with him, the utility of it was simply logical separation between layer three, and the interface between layer three and layer four. That said, he doesn't feel strongly enough about this to prevent what you suggest. There are lots of "changes" (which look like they aren't really changes) to the python bindings in this diff...I guess this is a result of running the pybindgen scanner for the updated API? So long as this is the case, please feel free to apply. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 12:42:31 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 15:42:31 -0400 Subject: [Ns-bugs] [Bug 282] Ipv4L4Demux is useful ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=282 ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-02 15:42 ------- (In reply to comment #4) > (In reply to comment #2) > > I am okay with this patch. I think we need to solicit some feedback from > > George, but I can't seem to add George as a CC... > > > > George has an account now, but that was another bug :-) > > After speaking with him, the utility of it was simply logical separation > between layer three, and the interface between layer three and layer four. > That said, he doesn't feel strongly enough about this to prevent what you > suggest. > > There are lots of "changes" (which look like they aren't really changes) to the > python bindings in this diff...I guess this is a result of running the > pybindgen scanner for the updated API? So long as this is the case, please > feel free to apply. yes, this is the result of running the scanner. > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 13:12:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 16:12:53 -0400 Subject: [Ns-bugs] [Bug 239] tcp has no finite size rcv buffer. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=239 raj.b at gatech.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ns-bugs at isi.edu |raj.b at gatech.edu Status|ASSIGNED |NEW Priority|P3 |P1 Version|pre-release |ns-3-dev ------- Comment #5 from raj.b at gatech.edu 2008-09-02 16:12 ------- Bump priority so this makes ns3.2 The repo is a little stale, but it works now. I did some unnecessary hacking, so instead of having this show up in our history I'm going to rebase, and roll this into one patch. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 13:32:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 16:32:49 -0400 Subject: [Ns-bugs] [Bug 288] --python-scan does not build everything.h before running In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=288 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-02 16:32 ------- I still get this bug in ns-3-dev HEAD as of today. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 14:30:44 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 17:30:44 -0400 Subject: [Ns-bugs] [Bug 288] --python-scan does not build everything.h before running In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=288 ------- Comment #3 from gjcarneiro at gmail.com 2008-09-02 17:30 ------- (In reply to comment #2) > I still get this bug in ns-3-dev HEAD as of today. What are you doing that expect everything.h to be rebuilt? Maybe I missed some dependency. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 14:35:14 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 17:35:14 -0400 Subject: [Ns-bugs] [Bug 288] --python-scan does not build everything.h before running In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=288 ------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-09-02 17:35 ------- I just modify a couple of headers in src/devices/wifi/ -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 2 17:23:38 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 02 Sep 2008 20:23:38 -0400 Subject: [Ns-bugs] [Bug 282] Ipv4L4Demux is useful ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=282 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #6 from mathieu.lacage at sophia.inria.fr 2008-09-02 20:23 ------- changeset ad0a36bfdb62 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 03:26:33 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 06:26:33 -0400 Subject: [Ns-bugs] [Bug 288] --python-scan does not build everything.h before running In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=288 ------- Comment #5 from gjcarneiro at gmail.com 2008-09-03 06:26 ------- (In reply to comment #4) > I just modify a couple of headers in src/devices/wifi/ I modified a couple of headers in src/devices/wifi and it worked. What particular headers does it not work with? If they are private headers... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 07:22:51 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 10:22:51 -0400 Subject: [Ns-bugs] [Bug 305] New: Tracing asserts too easily now Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=305 Summary: Tracing asserts too easily now Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com With this simple tracing code: http://code.nsnam.org/gjc/ns-3-pyviz/rev/6eccb090137c This happens: Incompatible types. (feed to "c++filt -t") got=N3ns318MemPtrCallbackImplIPNS_5PyVizEMS1_FvSsNS_3PtrIKNS_6PacketEEENS_12Mac48AddressEEvSsS6_S7_NS_5emptyESA_SA_EE, expected=PN3ns312CallbackImplIvSsNS_3PtrIKNS_6PacketEEENS_5emptyES5_S5_S5_EE Command ['/usr/bin/python', 'examples/mixed-wireless.py'] exited with code -11 It turns out that CsmaNetDevice and WifiNetDevice have different Tx/Rx trace event signatures: wifi: TracedCallback, Mac48Address> m_rxLogger; csma: TracedCallback > m_rxTrace; The code asserted when connecting on a csma netdevice, which has a different signature. Why they have different signatures is another problem. Right now I am concerned about why TraceConnect asserts. Why does this common use case of catching every transmission have to be so damn hard in NS-3? :-( Thoughts? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 08:18:29 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 11:18:29 -0400 Subject: [Ns-bugs] [Bug 305] Tracing asserts too easily now In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=305 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-03 11:18 ------- There is no such thing as "connect to all tx events" and I said so many times. You have to be specific to request to which events you want to connect. I would suggest using the $ns3::CsmaNetDevice notation: "/NodeList/*/DeviceList/*/$ns3::CsmaNetDevice/Tx" "/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Tx" If you want an API which hides this, you need to use the Helper API. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 09:51:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 12:51:53 -0400 Subject: [Ns-bugs] [Bug 305] Tracing asserts too easily now In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=305 ------- Comment #2 from gjcarneiro at gmail.com 2008-09-03 12:51 ------- OK, cool trick, but not easy to come up with the idea :P Maybe we need a FAQ, or code snippets repository :) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 09:57:02 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 12:57:02 -0400 Subject: [Ns-bugs] [Bug 305] Tracing asserts too easily now In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=305 ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-03 12:57 ------- (In reply to comment #2) > OK, cool trick, but not easy to come up with the idea :P > Maybe we need a FAQ, or code snippets repository :) I am all for a FAQ and I will fill answers for questions added there. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 14:04:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 17:04:55 -0400 Subject: [Ns-bugs] [Bug 306] New: nsc: -ldl dependency problem Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 Summary: nsc: -ldl dependency problem Product: ns-3 Version: ns-3.2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: tomh at tomh.org The following fails on ns-3.2 RC1 and ns-3-dev (from ns-regression): ./waf configure --nsc ./waf details are in the IRC log starting at 15:35: http://colabti.org/irclogger/irclogger_log/ns-3?date=2008-09-03,Wed -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 14:12:09 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 17:12:09 -0400 Subject: [Ns-bugs] [Bug 306] nsc: -ldl dependency problem In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-03 17:12 ------- patch: http://strlen.de/cradle/ns-3-nsc-libdl.patch -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 14:15:02 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 17:15:02 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-03 17:15 ------- I don't think that this bug is fixable. I would like to suggest that we disable python bindings on cygwin unless the user installs gccxml. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 14:32:02 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 17:32:02 -0400 Subject: [Ns-bugs] [Bug 304] wifi does not support bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=304 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 14:48:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 17:48:03 -0400 Subject: [Ns-bugs] [Bug 307] New: pybindgen not fetchable via web proxy Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 Summary: pybindgen not fetchable via web proxy Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: tomh at tomh.org I've not been able to retrieve pybindgen from behind a proxy, despite setting https_proxy and Ubuntu Preferences->Network Proxy. Is there some other way to configure proxy support for bzr? This is a typical error: Trying to fetch pybindgen; this will fail if no network connection is available. => /usr/bin/bzr checkout -rrevno:572 https://launchpad.net/pybindgen /home/user/hg/ns-3-dev/bindings/python/pybindgen bzr: ERROR: Invalid url supplied to transport: "Host empty in: proxy.example.com" I'm not sure whether this is a bzr problem (have Googled and found some people asking about bzr's proxy support) but I think that, regardless, if this occurs, a more prominent error should display at the end of ./waf configure that alerts the user to the lack of Python support. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 14:49:44 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 17:49:44 -0400 Subject: [Ns-bugs] [Bug 308] New: build fails on i386 machine unless python disabled Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=308 Summary: build fails on i386 machine unless python disabled Product: ns-3 Version: ns-3.2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: python bindings AssignedTo: ns-bugs at isi.edu ReportedBy: tomh at tomh.org machine: ns-old.ee.washington.edu (i386 Linux), python 2.4.3 (unfortunately, can't access this machine or a machine that can fetch pybindgen from my current location, so I can't give more detailed error log at this time) ./waf configure --python-disable works on this machine -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 15:06:36 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 18:06:36 -0400 Subject: [Ns-bugs] [Bug 308] build fails on i386 machine unless python disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=308 ------- Comment #1 from tomh at tomh.org 2008-09-03 18:06 ------- ns-old:~/hg/ns-3-dev$ ./waf Entering directory `/home/tomh/hg/ns-3-dev/build' [211/532] command-output: bindings/python/ns3modulegen.py build/debug/bindings/python/everything.h bindings/python/ns3modulegen_generated.py bindings/python/ns3modulegen_core_customizations.py bindings/python/ns3_module_node.py bindings/python/ns3_module_bridge.py bindings/python/ns3_module_csma.py bindings/python/ns3_module_simulator.py bindings/python/ns3_module_mobility.py bindings/python/ns3_module_olsr.py bindings/python/ns3_module_packet_sink.py bindings/python/ns3_module_wifi.py bindings/python/ns3_module_onoff.py bindings/python/ns3_module_stats.py bindings/python/ns3_module_global_routing.py bindings/python/ns3_module_internet_stack.py bindings/python/ns3_module_udp_echo.py bindings/python/ns3_module_contrib.py bindings/python/ns3_module_common.py bindings/python/ns3_module_helper.py bindings/python/ns3_module_core.py bindings/python/ns3_module_point_to_point.py -> build/debug/bindings/python/ns3module.cc build/debug/bindings/python/ns3modulegen.log build/debug/bindings/python/ns3module.h build/debug/bindings/python/ns3_module_node.cc build/debug/bindings/python/ns3_module_bridge.cc build/debug/bindings/python/ns3_module_csma.cc build/debug/bindings/python/ns3_module_simulator.cc build/debug/bindings/python/ns3_module_mobility.cc build/debug/bindings/python/ns3_module_olsr.cc build/debug/bindings/python/ns3_module_packet_sink.cc build/debug/bindings/python/ns3_module_wifi.cc build/debug/bindings/python/ns3_module_onoff.cc build/debug/bindings/python/ns3_module_stats.cc build/debug/bindings/python/ns3_module_global_routing.cc build/debug/bindings/python/ns3_module_internet_stack.cc build/debug/bindings/python/ns3_module_udp_echo.cc build/debug/bindings/python/ns3_module_contrib.cc build/debug/bindings/python/ns3_module_common.cc build/debug/bindings/python/ns3_module_helper.cc build/debug/bindings/python/ns3_module_core.cc build/debug/bindings/python/ns3_module_point_to_point.cc Build failed -> task failed (err #1): [bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3module.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3modulegen.log, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3module.h, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_node.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_bridge.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_csma.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_simulator.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_mobility.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_olsr.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_packet_sink.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_wifi.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_onoff.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_stats.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_global_routing.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_internet_stack.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_udp_echo.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_contrib.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_common.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_helper.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_core.cc, bld:///home/tomh/hg/ns-3-dev/bindings/python/ns3_module_point_to_point.cc] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 15:27:38 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 18:27:38 -0400 Subject: [Ns-bugs] [Bug 309] New: ns-3.2 RC1 build fails on FreeBSD7 Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 Summary: ns-3.2 RC1 build fails on FreeBSD7 Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: tomh at tomh.org (marked as simulation core for now-- need to add a "contrib" component) [281/532] cxx: src/contrib/gtk-config-store.cc -> build/debug/src/contrib/gtk-config-store_1.o cc1plus: warnings being treated as errors ../src/contrib/gtk-config-store.cc: In function 'void ns3::cell_data_function_col_1(GtkTreeViewColumn*, GtkCellRenderer*, GtkTreeModel*, GtkTreeIter*, void*)': ../src/contrib/gtk-config-store.cc:180: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:181: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:185: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:186: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc: In function 'void ns3::cell_data_function_col_0(GtkTreeViewColumn*, GtkCellRenderer*, GtkTreeModel*, GtkTreeIter*, void*)': ../src/contrib/gtk-config-store.cc:199: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:202: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:205: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:208: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:213: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:216: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc: In function 'GtkWidget* ns3::create_view(GtkTreeStore*)': ../src/contrib/gtk-config-store.cc:352: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc:364: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc: In function 'void ns3::save_clicked(GtkButton*, void*)': ../src/contrib/gtk-config-store.cc:395: warning: missing sentinel in function call ../src/contrib/gtk-config-store.cc: In function 'void ns3::load_clicked(GtkButton*, void*)': ../src/contrib/gtk-config-store.cc:429: warning: missing sentinel in function call Build failed -> task failed (err #129): [bld:///usr/home/core/ns/ns-3.2-RC1/src/contrib/gtk-config-store_1.o] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 17:19:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 20:19:11 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-03 20:19 ------- could this be a 64 bit box ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 17:34:38 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 03 Sep 2008 20:34:38 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-03 20:34 ------- Created an attachment (id=238) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=238&action=view) tentative patch Please, test and report -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 3 21:41:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 00:41:34 -0400 Subject: [Ns-bugs] [Bug 310] New: Python Bindings Build Error in Cygwin Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=310 Summary: Python Bindings Build Error in Cygwin Product: ns-3 Version: ns-3-dev Platform: PC OS/Version: Windows Status: NEW Severity: critical Priority: P2 Component: python bindings AssignedTo: ns-bugs at isi.edu ReportedBy: gavinweng at gmail.com have pygccxml,gccxml [470/530] cxx: build/debug/bindings/python/ns3module.cc -> build/debug/bindings/ python/ns3module_3.o In file included from debug/bindings/python/ns3module.cc:1: debug/bindings/python/ns3module.h: In member function `void PyNs3PacketCounterCa lculator__PythonHelper::Output__parent_caller(ns3::DataOutputCallback&)': debug/bindings/python/ns3module.h:6136: error: cannot call member function `void ns3::CounterCalculator::Output(ns3::DataOutputCallback&) const [with T = uns igned int]' without object debug/bindings/python/ns3module.h: In member function `void PyNs3PacketSizeMinMa xAvgTotalCalculator__PythonHelper::Output__parent_caller(ns3::DataOutputCallback &)': debug/bindings/python/ns3module.h:6213: error: cannot call member function `void ns3::MinMaxAvgTotalCalculator::Output(ns3::DataOutputCallback&) const [with T = unsigned int]' without object debug/ns3/basic-data-calculators.h: In member function `void ns3::CounterCalcula tor::Output(ns3::DataOutputCallback&) const [with T = unsigned int]': debug/bindings/python/ns3module.h:5781: instantiated from here debug/ns3/basic-data-calculators.h:181: error: call of overloaded `OutputSinglet on(const std::string&, const char[6], const unsigned int&)' is ambiguous debug/ns3/data-output-interface.h:52: note: candidates are: virtual void ns3::Da taOutputCallback::OutputSingleton(std::string, std::string, int) debug/ns3/data-output-interface.h:56: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, uint32_t) debug/ns3/data-output-interface.h:60: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, double) debug/ns3/data-output-interface.h:64: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, std::string) debug/bindings/python/ns3module.h:5996: instantiated from here debug/ns3/basic-data-calculators.h:97: error: call of overloaded `OutputSingleto n(const std::string&, const char[4], const unsigned int&)' is ambiguous debug/ns3/data-output-interface.h:52: note: candidates are: virtual void ns3::Da taOutputCallback::OutputSingleton(std::string, std::string, int) debug/ns3/data-output-interface.h:56: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, uint32_t) debug/ns3/data-output-interface.h:60: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, double) debug/ns3/data-output-interface.h:64: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, std::string) debug/ns3/basic-data-calculators.h:98: error: call of overloaded `OutputSingleto n(const std::string&, const char[4], const unsigned int&)' is ambiguous debug/ns3/data-output-interface.h:52: note: candidates are: virtual void ns3::Da taOutputCallback::OutputSingleton(std::string, std::string, int) debug/ns3/data-output-interface.h:56: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, uint32_t) debug/ns3/data-output-interface.h:60: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, double) debug/ns3/data-output-interface.h:64: note: virtual void ns3::DataOutputCallbac k::OutputSingleton(std::string, std::string, std::string) Build failed -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 03:55:33 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 06:55:33 -0400 Subject: [Ns-bugs] [Bug 310] Python Bindings Build Error in Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=310 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #1 from gjcarneiro at gmail.com 2008-09-04 06:55 ------- This is due to a gccxml bug: http://www.gccxml.org/Bug/view.php?id=7572 You might get away with it by re-scanning API definitions from within the cygwin environment (./waf --python-scan). However the most likely solution will probably have to be that we disable python bindings in CygWin. If you really care about Python bindings, try building with mingw and native python instead. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 03:57:31 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 06:57:31 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 ------- Comment #3 from gjcarneiro at gmail.com 2008-09-04 06:57 ------- *** Bug 310 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 03:57:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 06:57:30 -0400 Subject: [Ns-bugs] [Bug 310] Python Bindings Build Error in Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=310 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #2 from gjcarneiro at gmail.com 2008-09-04 06:57 ------- *** This bug has been marked as a duplicate of bug 297 *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 04:06:02 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 07:06:02 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #1 from gjcarneiro at gmail.com 2008-09-04 07:06 ------- (In reply to comment #0) > I've not been able to retrieve pybindgen from behind a proxy, despite setting > https_proxy and Ubuntu Preferences->Network Proxy. Is there some other way to > configure proxy support for bzr? > > This is a typical error: > Trying to fetch pybindgen; this will fail if no network connection is > available. > => /usr/bin/bzr checkout -rrevno:572 https://launchpad.net/pybindgen > /home/user/hg/ns-3-dev/bindings/python/pybindgen > bzr: ERROR: Invalid url supplied to transport: "Host empty in: > proxy.example.com" > > I'm not sure whether this is a bzr problem (have Googled and found some people > asking about bzr's proxy support) Try upgrading bzr, or setting the http_proxy environment variable. Luckily in the release tarballs bzr will not be used, so this is a problem for ns-3 developers only. > but I think that, regardless, if this occurs, > a more prominent error should display at the end of ./waf configure that alerts > the user to the lack of Python support. So you are saying that lack of Python support is more important than e.g. lack of Gtk support, so that it deserves an additional warning in the end? Or do you think we should perhaps present a summary in the end of all optional features, saying if they are enabled or not? If seen such summaries in some configure scripts in some projects before... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 05:26:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 08:26:04 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 ------- Comment #2 from tomh at tomh.org 2008-09-04 08:26 ------- > > I'm not sure whether this is a bzr problem (have Googled and found some people > > asking about bzr's proxy support) > > Try upgrading bzr, or setting the http_proxy environment variable. Luckily in > the release tarballs bzr will not be used, so this is a problem for ns-3 > developers only. setting http_proxy has no effect. Agree this is mainly a development problem. I didn't mark it as high priority; is more of an inconvenience, along the lines of the thread Mathieu started yesterday. However, I am able to get other pieces through a proxy. > > > but I think that, regardless, if this occurs, > > a more prominent error should display at the end of ./waf configure that alerts > > the user to the lack of Python support. > > So you are saying that lack of Python support is more important than e.g. lack > of Gtk support, so that it deserves an additional warning in the end? Or do > you think we should perhaps present a summary in the end of all optional > features, saying if they are enabled or not? If seen such summaries in some > configure scripts in some projects before... > I think it would be helpful to have an output showing optionally configured pieces; e.g. Configuration status of ns-3 optional components: ------------------------------------------------- Python bindings: enabled nsc: disabled ... I think Mathieu's proposal will also help to clearly identify what was successfully downloaded or not. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 05:34:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 08:34:32 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 ------- Comment #3 from gjcarneiro at gmail.com 2008-09-04 08:34 ------- Correction: in this case you need to define https_proxy, not http_proxy. I had not read Mathieu's proposal. Commented now. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 05:40:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 08:40:42 -0400 Subject: [Ns-bugs] [Bug 308] build fails on i386 machine unless python disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=308 ------- Comment #2 from gjcarneiro at gmail.com 2008-09-04 08:40 ------- I suspect this "build fails with Python 2.4", because I am having such a problem: cc1plus: warnings being treated as errors debug/bindings/python/ns3_module_core.cc:1096: warning: deprecated conversion from string constant to ?char*? debug/bindings/python/ns3_module_core.cc:1306: warning: deprecated conversion from string constant to ?char*? debug/bindings/python/ns3_module_core.cc:1602: warning: deprecated conversion from string constant to ?char*? debug/bindings/python/ns3_module_core.cc:1756: warning: deprecated conversion from string constant to ?char*? [...] Should be easy to fix in PyBindGen, now that I know what Python version to test... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 05:45:01 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 08:45:01 -0400 Subject: [Ns-bugs] [Bug 310] Python Bindings Build Error in Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=310 ------- Comment #3 from tomh at tomh.org 2008-09-04 08:45 ------- (In reply to comment #1) > This is due to a gccxml bug: http://www.gccxml.org/Bug/view.php?id=7572 > > You might get away with it by re-scanning API definitions from within the > cygwin environment (./waf --python-scan). However the most likely solution > will probably have to be that we disable python bindings in CygWin. > > If you really care about Python bindings, try building with mingw and native > python instead. > I added the above information to the python wiki page and linked to it from the Troubleshooting page. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 05:50:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 08:50:34 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 ------- Comment #4 from tomh at tomh.org 2008-09-04 08:50 ------- (In reply to comment #3) > Correction: in this case you need to define https_proxy, not http_proxy. > > I had not read Mathieu's proposal. Commented now. > Yes, I tried setting both of them. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 06:17:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 09:17:42 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 ------- Comment #5 from gjcarneiro at gmail.com 2008-09-04 09:17 ------- I have bzr 1.3.1, and I am behind a company http firewall. Setting both: export http_proxy=http://proxy:3128 export https_proxy=http://proxy:3128 Makes bzr work for me. I have to export both variables at the same time, though. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 06:19:26 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 09:19:26 -0400 Subject: [Ns-bugs] [Bug 308] build fails on i386 machine unless python disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=308 ------- Comment #3 from gjcarneiro at gmail.com 2008-09-04 09:19 ------- (In reply to comment #2) > I suspect this "build fails with Python 2.4", because I am having such a > problem: > cc1plus: warnings being treated as errors > debug/bindings/python/ns3_module_core.cc:1096: warning: deprecated conversion > from string constant to ?char*? > debug/bindings/python/ns3_module_core.cc:1306: warning: deprecated conversion > from string constant to ?char*? > debug/bindings/python/ns3_module_core.cc:1602: warning: deprecated conversion > from string constant to ?char*? > debug/bindings/python/ns3_module_core.cc:1756: warning: deprecated conversion > from string constant to ?char*? > [...] > > Should be easy to fix in PyBindGen, now that I know what Python version to > test... > This should be fixed now. If it's the same bug as what is being reported here, then we can close. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 08:24:26 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 11:24:26 -0400 Subject: [Ns-bugs] [Bug 306] nsc: -ldl dependency problem In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #2 from tomh at tomh.org 2008-09-04 11:24 ------- this was fixed yesterday in changeset 693faf7f439b -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 08:38:08 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 11:38:08 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 ------- Comment #6 from tomh at tomh.org 2008-09-04 11:38 ------- (In reply to comment #5) > I have bzr 1.3.1, and I am behind a company http firewall. Setting both: > > export http_proxy=http://proxy:3128 > export https_proxy=http://proxy:3128 > > Makes bzr work for me. I have to export both variables at the same time, > though. > I tried this again today; no luck: bzr: ERROR: Invalid http response for https://launchpad.net/pybindgen/.bzr/branch-format: Unable to handle http code 400: Bad Request I'm on bzr-1.3.1 also, on Ubuntu. Maybe this is just a local proxy problem for me, though, since you were able to get it to work. mark it as WORKSFORME? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 08:41:12 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 11:41:12 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 ------- Comment #3 from tomh at tomh.org 2008-09-04 11:41 ------- (In reply to comment #2) > Created an attachment (id=238) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=238&action=view) [details] > tentative patch > > Please, test and report > Your patch worked and ns-3 built. However, it led to another problem: $ ./waf check Entering directory `/usr/home/ns/ns-3.2-RC1/build' Compilation finished successfully WARNING Don't know how to configure dynamic library path for the platform 'freebsd7' /libexec/ld-elf.so.1: Shared object "libns3.so" not found, required by "print-introspected-doxygen" btw, it is a 32-bit box -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 08:43:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 11:43:45 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-09-04 11:43 ------- gustavo, any idea ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 08:59:14 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 11:59:14 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-04 11:59 ------- btw, what version of gcc ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 10:20:43 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 13:20:43 -0400 Subject: [Ns-bugs] [Bug 307] pybindgen not fetchable via web proxy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=307 ------- Comment #7 from gjcarneiro at gmail.com 2008-09-04 13:20 ------- One way to confirm whether it is a proxy problem would be to open the URL on the web browser: https://launchpad.net/pybindgen/.bzr/branch-format You should receive the text page containing: Bazaar-NG meta directory, format 1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 10:31:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 13:31:30 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 ------- Comment #6 from gjcarneiro at gmail.com 2008-09-04 13:31 ------- Should be fixed now. Confirm? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:09:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:09:55 -0400 Subject: [Ns-bugs] [Bug 311] Tcp socket close returns -1 but does not set errno. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=311 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-04 16:09 ------- I should have pointed out that, if the purpose is to guard against a double-close, then, the socket should not be initialized to CLOSED state in the TcpSocketImpl constructor because this would trigger an EBADF upon closing a socket which was just opened. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:08:12 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:08:12 -0400 Subject: [Ns-bugs] [Bug 311] New: Tcp socket close returns -1 but does not set errno. Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=311 Summary: Tcp socket close returns -1 but does not set errno. Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr tcp-socket-impl.cc: line 294: if (m_state == CLOSED) { return -1; } It is illegal to return -1 without setting errno. But I have to confess that I don't really understand the purpose of this check: is it expected to guard against a double close ? If so, I suspect that the return errno here is EBADF. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:17:52 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:17:52 -0400 Subject: [Ns-bugs] [Bug 312] New: ./waf check fails Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=312 Summary: ./waf check fails Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu Working out of ns-3-dev, 3622:a74c78bfc304, Python 2.5.2, x86 Ubuntu. The error is: raj at raj-desktop:~/code.nsnam.org/ns-3-dev$ ./waf check Entering directory `/home/raj/code.nsnam.org/ns-3-dev/build' Compilation finished successfully -- Running NS-3 C++ core unit tests... Traceback (most recent call last): File "./waf", line 141, in Scripting.prepare() File "/home/raj/code.nsnam.org/ns-3-dev/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 207, in prepare main() File "/home/raj/code.nsnam.org/ns-3-dev/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 299, in main if fun:fun() File "/home/raj/code.nsnam.org/ns-3-dev/wscript", line 451, in shutdown _run_waf_check() File "/home/raj/code.nsnam.org/ns-3-dev/wscript", line 492, in _run_waf_check run_program('run-tests', get_command_template()) TypeError: get_command_template() takes exactly 1 argument (0 given) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:28:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:28:45 -0400 Subject: [Ns-bugs] [Bug 312] ./waf check fails In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=312 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-04 16:28 ------- changeset 5209cecd2ade -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:37:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:37:21 -0400 Subject: [Ns-bugs] [Bug 313] New: regression test fails Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 Summary: regression test fails Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu I get a regression on x86 Ubuntu, Linux 2.6.24, gcc 4.2.3. This is out of ns-3-dev, 3623:5209cecd2ade. diff output appears below. raj at raj-desktop:~/code.nsnam.org/ns-3-dev$ ./waf --regression --regression-tests=test-wifi-wired-bridging Entering directory `/home/raj/code.nsnam.org/ns-3-dev/build' Compilation finished successfully ========== Running Regression Tests ========== Synchronizing reference traces using Mercurial. Pulling http://code.nsnam.org/ns-3-dev-ref-traces from repo. Done. ---------- Traces differ in test: test-wifi-wired-bridging Reference traces in directory: regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref Traces in directory: traces Rerun regression test as: "./waf --regression --regression-tests=test-wifi-wired-bridging" Then do "diff -u regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref regression/traces" for details ---------- FAIL test-wifi-wired-bridging raj at raj-desktop:~/code.nsnam.org/ns-3-dev$ diff -u regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref regression/traces Binary files regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref/wifi-wire-bridging-2-0.pcap and regression/traces/wifi-wire-bridging-2-0.pcap differ Binary files regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref/wifi-wire-bridging-5-0.pcap and regression/traces/wifi-wire-bridging-5-0.pcap differ diff -u regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref/wifi-wire-bridging.mob regression/traces/wifi-wire-bridging.mob --- regression/ns-3-dev-ref-traces/wifi-wired-bridging.ref/wifi-wire-bridging.mob 2008-09-04 16:22:51.000000000 -0400 +++ regression/traces/wifi-wire-bridging.mob 2008-09-04 16:32:48.000000000 -0400 @@ -25,7 +25,7 @@ now=10000000000ns node=4 pos=22.7411:3.27673:0 vel=0.365892:-0.930657:0 now=10000000000ns node=5 pos=22.3088:7.17788:0 vel=0.346605:-0.938011:0 now=11165644633ns node=2 pos=1.6767:3.70263e-10:0 vel=-0.384132:0.923278:0 -now=11365467357ns node=3 pos=4.06829e-10:13.2634:0 vel=0.82771:-0.561157:0 +now=11365467357ns node=3 pos=4.06828e-10:13.2634:0 vel=0.82771:-0.561157:0 now=11999999998ns node=2 pos=1.35619:0.770342:0 vel=-0.934307:-0.35647:0 now=11999999998ns node=3 pos=0.525209:12.9073:0 vel=0.693444:0.720511:0 now=12000000000ns node=4 pos=23.4728:1.41541:0 vel=0.756324:0.654198:0 @@ -35,7 +35,7 @@ now=13999999998ns node=3 pos=1.9121:14.3483:0 vel=-0.93504:-0.354543:0 now=14000000000ns node=4 pos=24.9855:2.72381:0 vel=-0.0443267:0.999017:0 now=14000000000ns node=5 pos=21.5485:6.67565:0 vel=0.110153:0.993915:0 -now=14524306279ns node=2 pos=9.96666e-11:0.168415:0 vel=0.977327:0.211733:0 +now=14524306279ns node=2 pos=9.96671e-11:0.168415:0 vel=0.977327:0.211733:0 now=15999999996ns node=2 pos=1.44224:0.480869:0 vel=0.970249:-0.242108:0 now=15999999998ns node=3 pos=0.0420166:13.6393:0 vel=0.963599:0.26735:0 now=16000000000ns node=4 pos=24.8968:4.72184:0 vel=0.8084:-0.588633:0 @@ -51,7 +51,7 @@ now=19999999998ns node=3 pos=0.0278309:14.6546:0 vel=-0.978461:-0.206432:0 now=19999999999ns node=4 pos=22.1952:5.07193:0 vel=0.874772:0.484534:0 now=20000000000ns node=5 pos=20.2717:8.61439:0 vel=-0.872226:-0.489102:0 -now=20028443561ns node=3 pos=5.50479e-10:14.6487:0 vel=0.978461:-0.206432:0 +now=20028443561ns node=3 pos=5.50478e-10:14.6487:0 vel=0.978461:-0.206432:0 now=20311492454ns node=5 pos=20:8.46204:0 vel=0.872226:-0.489102:0 now=21999999994ns node=2 pos=3.42627:0.0196114:0 vel=-0.134922:-0.990856:0 now=21999999997ns node=3 pos=1.92909:14.2417:0 vel=-0.209447:0.97782:0 @@ -63,7 +63,7 @@ now=23999999996ns node=3 pos=1.5102:13.8026:0 vel=-0.928298:0.371838:0 now=23999999999ns node=4 pos=23.3487:4.13188:0 vel=0.619341:-0.785122:0 now=23999999999ns node=5 pos=21.1591:5.66094:0 vel=0.927023:-0.375004:0 -now=25626846437ns node=3 pos=3.65209e-10:14.4075:0 vel=0.928298:0.371838:0 +now=25626846437ns node=3 pos=3.65208e-10:14.4075:0 vel=0.928298:0.371838:0 now=25999999993ns node=2 pos=3.55578:0.00237744:0 vel=-0.923916:0.382596:0 now=25999999995ns node=3 pos=0.346398:14.5463:0 vel=0.165283:0.986246:0 now=25999999999ns node=4 pos=24.5873:2.56163:0 vel=-0.0593576:0.998237:0 @@ -73,13 +73,13 @@ now=27999999994ns node=3 pos=0.676964:13.4812:0 vel=-0.743507:-0.668728:0 now=27999999999ns node=4 pos=24.4686:4.55811:0 vel=-0.877937:0.478777:0 now=27999999999ns node=5 pos=23.3345:2.93692:0 vel=0.708358:0.705853:0 -now=28910500858ns node=3 pos=7.26399e-10:12.8723:0 vel=0.743507:-0.668728:0 +now=28910500858ns node=3 pos=7.26398e-10:12.8723:0 vel=0.743507:-0.668728:0 now=29999999993ns node=2 pos=1.00512:2.64001:0 vel=-0.768359:0.640019:0 now=29999999993ns node=3 pos=0.810051:12.1438:0 vel=-0.596321:-0.802746:0 now=29999999999ns node=4 pos=22.7128:5.51566:0 vel=0.657668:0.753308:0 now=29999999999ns node=5 pos=24.7513:4.34863:0 vel=-0.874395:0.485215:0 -now=31308139922ns node=2 pos=2.14209e-10:3.47724:0 vel=0.768359:0.640019:0 -now=31358413028ns node=3 pos=5.58113e-10:11.0533:0 vel=0.596321:-0.802746:0 +now=31308139922ns node=2 pos=2.1421e-10:3.47724:0 vel=0.768359:0.640019:0 +now=31358413028ns node=3 pos=5.58112e-10:11.0533:0 vel=0.596321:-0.802746:0 now=31999999992ns node=2 pos=0.531597:3.92005:0 vel=0.998094:-0.0617076:0 now=31999999992ns node=3 pos=0.382592:10.5383:0 vel=0.678162:-0.734912:0 now=31999999999ns node=4 pos=24.0281:7.02228:0 vel=0.540337:0.841449:0 @@ -167,8 +167,8 @@ now=65999999990ns node=3 pos=3.51686:0.701129:0 vel=-0.217758:-0.976003:0 now=65999999994ns node=4 pos=23.5698:11.7258:0 vel=-0.22736:0.973811:0 now=65999999995ns node=5 pos=22.0696:13.8635:0 vel=-0.969652:0.244489:0 -now=66333264228ns node=2 pos=8.84258e-10:6.45125:0 vel=0.991146:-0.132775:0 -now=66718367740ns node=3 pos=3.36043:5.86401e-10:0 vel=-0.217758:0.976003:0 +now=66333264228ns node=2 pos=8.8426e-10:6.45125:0 vel=0.991146:-0.132775:0 +now=66718367740ns node=3 pos=3.36043:5.86402e-10:0 vel=-0.217758:0.976003:0 now=67999999987ns node=2 pos=1.65198:6.22995:0 vel=-0.958349:-0.2856:0 now=67999999989ns node=3 pos=3.08134:1.25088:0 vel=0.96961:0.244655:0 now=67999999994ns node=4 pos=23.1151:13.6734:0 vel=0.417676:0.908596:0 @@ -176,14 +176,14 @@ now=68166970011ns node=5 pos=20:14.4569:0 vel=0.780574:0.625064:0 now=69035911767ns node=5 pos=20.6783:15:0 vel=0.780574:-0.625064:0 now=69460037914ns node=4 pos=23.7249:15:0 vel=0.417676:-0.908596:0 -now=69723776128ns node=2 pos=5.47653e-10:5.73764:0 vel=0.958349:-0.2856:0 +now=69723776128ns node=2 pos=5.47655e-10:5.73764:0 vel=0.958349:-0.2856:0 now=69978796189ns node=3 pos=5:1.735:0 vel=-0.96961:0.244655:0 now=69999999986ns node=2 pos=0.264719:5.65875:0 vel=-0.79604:-0.605244:0 now=69999999988ns node=3 pos=4.97944:1.74019:0 vel=0.551491:0.834181:0 now=69999999993ns node=5 pos=21.4308:14.3974:0 vel=0.95505:0.296445:0 now=69999999993ns node=4 pos=23.9505:14.5094:0 vel=-0.969184:0.246337:0 now=70037279673ns node=3 pos=5:1.77128:0 vel=-0.551491:0.834181:0 -now=70332544490ns node=2 pos=5.78141e-10:5.45748:0 vel=0.79604:-0.605244:0 +now=70332544490ns node=2 pos=5.78143e-10:5.45748:0 vel=0.79604:-0.605244:0 now=71991611832ns node=4 pos=22.0202:15:0 vel=-0.969184:-0.246337:0 now=71999999985ns node=2 pos=1.32736:4.44826:0 vel=-0.67504:-0.737782:0 now=71999999987ns node=3 pos=3.91758:3.40855:0 vel=-0.890062:0.455839:0 @@ -191,12 +191,12 @@ now=71999999993ns node=5 pos=23.3409:14.9903:0 vel=-0.76366:0.645619:0 now=72007625050ns node=4 pos=22.0194:15:0 vel=0.962582:-0.27099:0 now=72015066987ns node=5 pos=23.3294:15:0 vel=-0.76366:-0.645619:0 -now=73966346519ns node=2 pos=4.86382e-10:2.99753:0 vel=0.67504:-0.737782:0 +now=73966346519ns node=2 pos=4.86383e-10:2.99753:0 vel=0.67504:-0.737782:0 now=73999999984ns node=2 pos=0.0227174:2.9727:0 vel=-0.889377:-0.457174:0 now=73999999987ns node=3 pos=2.13745:4.32023:0 vel=-0.90497:0.425475:0 now=73999999991ns node=4 pos=23.9373:14.4601:0 vel=0.654438:0.756115:0 now=73999999992ns node=5 pos=21.8136:13.7185:0 vel=0.807235:0.590231:0 -now=74025543044ns node=2 pos=5.9056e-10:2.96102:0 vel=0.889377:-0.457174:0 +now=74025543044ns node=2 pos=5.90562e-10:2.96102:0 vel=0.889377:-0.457174:0 now=74714062214ns node=4 pos=24.4046:15:0 vel=0.654438:-0.756115:0 now=75623882100ns node=4 pos=25:14.3121:0 vel=-0.654438:-0.756115:0 now=75999999983ns node=2 pos=1.75604:2.05835:0 vel=-0.466643:-0.884446:0 @@ -204,7 +204,7 @@ now=75999999989ns node=4 pos=24.7539:14.0277:0 vel=0.0834669:0.996511:0 now=75999999992ns node=5 pos=23.4281:14.899:0 vel=0.773144:0.634231:0 now=76159325208ns node=5 pos=23.5512:15:0 vel=0.773144:-0.634231:0 -now=76485062737ns node=3 pos=1.52141e-10:4.81338:0 vel=0.675196:-0.737638:0 +now=76485062737ns node=3 pos=1.52142e-10:4.81338:0 vel=0.675196:-0.737638:0 now=76975721945ns node=4 pos=24.8353:15:0 vel=0.0834669:-0.996511:0 now=77999999983ns node=2 pos=0.822752:0.289461:0 vel=0.775889:0.63087:0 now=77999999986ns node=3 pos=1.02288:3.6959:0 vel=0.867724:-0.497046:0 @@ -221,7 +221,7 @@ now=81999999987ns node=4 pos=23.2478:14.8764:0 vel=-0.837758:0.546042:0 now=81999999990ns node=5 pos=21.9743:12.71:0 vel=0.997758:0.0669273:0 now=82226436527ns node=4 pos=23.0581:15:0 vel=-0.837758:-0.546042:0 -now=83219588242ns node=3 pos=7.55837e-10:1.90894:0 vel=0.944913:0.32732:0 +now=83219588242ns node=3 pos=7.55838e-10:1.90894:0 vel=0.944913:0.32732:0 now=83999999983ns node=2 pos=2.69154:2.51078:0 vel=-0.341213:0.939986:0 now=83999999985ns node=3 pos=0.737422:2.16439:0 vel=0.0173346:0.99985:0 now=83999999986ns node=4 pos=21.5723:14.0316:0 vel=-0.860932:0.50872:0 @@ -234,18 +234,18 @@ now=85999999990ns node=5 pos=24.8388:11.0425:0 vel=0.95288:-0.303349:0 now=86169168544ns node=5 pos=25:10.9912:0 vel=-0.95288:-0.303349:0 now=86188296209ns node=4 pos=20:14.8366:0 vel=0.794176:-0.607687:0 -now=86917280917ns node=3 pos=8.40541e-11:3.66883:0 vel=0.841717:-0.539919:0 +now=86917280917ns node=3 pos=8.4055e-11:3.66883:0 vel=0.841717:-0.539919:0 now=87999999983ns node=2 pos=1.6863:6.36453:0 vel=-0.746964:0.664864:0 now=87999999983ns node=4 pos=21.4388:13.7356:0 vel=0.987429:-0.158063:0 now=87999999984ns node=3 pos=0.911343:3.08425:0 vel=-0.561505:0.827473:0 now=87999999989ns node=5 pos=23.2554:10.4358:0 vel=0.92864:-0.370982:0 -now=89623035902ns node=3 pos=1.06093e-10:4.42727:0 vel=0.561505:0.827473:0 +now=89623035902ns node=3 pos=1.06094e-10:4.42727:0 vel=0.561505:0.827473:0 now=89878620082ns node=5 pos=25:9.73885:0 vel=-0.92864:-0.370982:0 now=89999999983ns node=2 pos=0.192373:7.69426:0 vel=0.309674:0.950843:0 now=89999999983ns node=4 pos=23.4137:13.4195:0 vel=-0.999769:-0.0214752:0 now=89999999983ns node=3 pos=0.211667:4.7392:0 vel=-0.996726:0.0808595:0 now=89999999988ns node=5 pos=24.8873:9.69382:0 vel=-0.99882:0.048569:0 -now=90212362596ns node=3 pos=5.11628e-10:4.75637:0 vel=0.996726:0.0808595:0 +now=90212362596ns node=3 pos=5.11629e-10:4.75637:0 vel=0.996726:0.0808595:0 now=91999999982ns node=3 pos=1.78178:4.90092:0 vel=0.970961:0.239236:0 now=91999999983ns node=2 pos=0.811721:9.59594:0 vel=0.640857:-0.76766:0 now=91999999983ns node=4 pos=21.4141:13.3766:0 vel=-0.150979:-0.988537:0 @@ -264,7 +264,7 @@ now=97999999983ns node=4 pos=23.5709:13.4131:0 vel=0.784543:-0.620074:0 now=97999999987ns node=5 pos=21.4272:9.91245:0 vel=-0.0610107:0.998137:0 now=99454620833ns node=3 pos=5:5.67055:0 vel=-0.974709:-0.223477:0 -now=99576222034ns node=2 pos=7.46729e-11:11.0674:0 vel=0.818622:-0.574333:0 +now=99576222034ns node=2 pos=7.46738e-11:11.0674:0 vel=0.818622:-0.574333:0 now=99821612562ns node=4 pos=25:12.2836:0 vel=-0.784543:-0.620074:0 now=99999999981ns node=3 pos=4.46841:5.54867:0 vel=-0.948169:-0.317765:0 now=99999999982ns node=2 pos=0.346914:10.824:0 vel=-0.490305:0.871551:0 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:50:19 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:50:19 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 ------- Comment #1 from raj.b at gatech.edu 2008-09-04 16:50 ------- Created an attachment (id=239) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=239&action=view) first pcap file generated -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 13:55:46 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 16:55:46 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 ------- Comment #3 from raj.b at gatech.edu 2008-09-04 16:55 ------- Also, here is the difference in tcpdump output on the pcap files. Dumps were generated with tcpdump -r blah.pcap -nn -tt, and diffs with the usual diff -u --- actual2.dump 2008-09-04 16:52:09.000000000 -0400 +++ expected2.dump 2008-09-04 16:52:31.000000000 -0400 @@ -1,11 +1,11 @@ 0.000150 Beacon (wifi-default-0) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS 0.000184 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000348 Acknowledgment RA:00:00:00:00:00:04 -0.000466 Assoc Response AID(1cb7) :: Succesful +0.000466 Assoc Response AID(0) :: Succesful 0.000482 Acknowledgment RA:00:00:00:00:00:03 0.000702 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000762 Acknowledgment RA:00:00:00:00:00:05 -0.000880 Assoc Response AID(1bb7) :: Succesful +0.000880 Assoc Response AID(0) :: Succesful 0.000940 Acknowledgment RA:00:00:00:00:00:03 0.508192 00:00:00:00:00:07 > 00:00:00:00:00:04 SNAP Unnumbered, ui, Flags [Command], length 524 0.509008 Acknowledgment RA:00:00:00:00:00:04 --- actual5.dump 2008-09-04 16:52:16.000000000 -0400 +++ expected5.dump 2008-09-04 16:52:42.000000000 -0400 @@ -1,10 +1,10 @@ -0.000150 Beacon[|802.11] +0.000150 Beacon (wifi-default-1) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS 0.000288 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000348 Acknowledgment RA:00:00:00:00:00:07 0.000382 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000805 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000969 Acknowledgment RA:00:00:00:00:00:08 -0.001087 Assoc Response AID(1bb7) :: Succesful +0.001087 Assoc Response AID(0) :: Succesful 0.001103 Acknowledgment RA:00:00:00:00:00:06 0.509705 00:00:00:00:00:07 > 00:00:00:00:00:04 SNAP Unnumbered, ui, Flags [Command], length 524 0.509765 Acknowledgment RA:00:00:00:00:00:06 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 16:26:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 04 Sep 2008 19:26:03 -0400 Subject: [Ns-bugs] [Bug 309] ns-3.2 RC1 build fails on FreeBSD7 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=309 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #7 from tomh at tomh.org 2008-09-04 19:26 ------- (In reply to comment #6) > Should be fixed now. Confirm? > Yes, ns-3-dev now works. I'll close it, thanks. By the way, it is gcc-4.2.1 on this machine. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 4 21:05:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 00:05:49 -0400 Subject: [Ns-bugs] [Bug 305] Tracing asserts too easily now In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=305 ------- Comment #4 from tomh at tomh.org 2008-09-05 00:05 ------- (In reply to comment #3) > (In reply to comment #2) > > OK, cool trick, but not easy to come up with the idea :P > > Maybe we need a FAQ, or code snippets repository :) > > I am all for a FAQ and I will fill answers for questions added there. > There are several places for this type of information. Joe started this page: http://www.nsnam.org/wiki/index.php/Category:Samples We also have a user FAQ: http://www.nsnam.org/wiki/index.php/User_FAQ Or the manual. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 08:55:22 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 11:55:22 -0400 Subject: [Ns-bugs] [Bug 308] build fails on i386 machine unless python disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=308 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #4 from gjcarneiro at gmail.com 2008-09-05 11:55 ------- OK, now should _really_ be fixed. I tested on ns-old.ee.washington.edu, thanks to Tom giving me access. It was a bug in Python itself (deepcopy), crazy as it sounds, so I just worked around it. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 10:02:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 13:02:55 -0400 Subject: [Ns-bugs] [Bug 314] New: NSC support wscript changes appear buggy Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 Summary: NSC support wscript changes appear buggy Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: build system AssignedTo: gjcarneiro at gmail.com ReportedBy: gjcarneiro at gmail.com CC: ns-bugs at isi.edu in src/internet-stack/wscript if arch == 'x86_64' or arch == 'i686' or arch == 'i586' or arch == 'i486' or arch == 'i386': conf.env['NSC_ENABLED'] = 'yes' conf.define('NETWORK_SIMULATION_CRADLE', 1) conf.write_config_header('ns3/core-config.h') e = conf.create_library_configurator() e.mandatory = True e.name = 'dl' e.define = 'HAVE_DL' e.uselib = 'DL' e.run() ok = True First, what is the "conf.write_config_header('ns3/core-config.h')" doing there? It overwrites an existing configuration header. Sounds like a copy paste error. I'll rename this header file to internet-stack-config.h, if no objections. Next, e.run() ok = True Shouldn't this be: ok = e.run() ? Finally I think it is more modular to move opt.add_option('--nsc', ...) from the toplevel wscript file into src/internet-stack/wscript, for better organization. I'll fix these things if no objections. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 10:04:25 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 13:04:25 -0400 Subject: [Ns-bugs] [Bug 314] NSC support wscript changes appear buggy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 ------- Comment #1 from gjcarneiro at gmail.com 2008-09-05 13:04 ------- Oh, I see now e.mandatory = True when checking for libdl. So never mind that part (assuming this is intentional). -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 10:53:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 13:53:07 -0400 Subject: [Ns-bugs] [Bug 314] NSC support wscript changes appear buggy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-05 13:53 ------- while you are at it, --nsc should be renamed to --nsc-enable to match what you did for --python-disable. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 11:11:50 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 14:11:50 -0400 Subject: [Ns-bugs] [Bug 314] NSC support wscript changes appear buggy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 ------- Comment #3 from tomh at tomh.org 2008-09-05 14:11 ------- (In reply to comment #2) > while you are at it, --nsc should be renamed to --nsc-enable to match what you > did for --python-disable. > While we are on the topic, is there any reason not to align the syntax with configure? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --python-disable instead of --disable-python has tripped me up in the past -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 11:17:39 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 14:17:39 -0400 Subject: [Ns-bugs] [Bug 314] NSC support wscript changes appear buggy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 ------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-09-05 14:17 ------- (In reply to comment #3) > (In reply to comment #2) > > while you are at it, --nsc should be renamed to --nsc-enable to match what you > > did for --python-disable. > > > > While we are on the topic, is there any reason not to align the syntax with > configure? +1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 11:18:54 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 14:18:54 -0400 Subject: [Ns-bugs] [Bug 314] NSC support wscript changes appear buggy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 ------- Comment #5 from gjcarneiro at gmail.com 2008-09-05 14:18 ------- I was just commenting about this on IRC. In principle I dislike --python-disable, and prefer --disable-python, but: gjc at dark-tower:ns-3-dev$ ./waf --python Usage: waf [options] [commands ...] * Main commands: configure build install clean dist distclean uninstall distcheck * Example: ./waf build -j4 waf: error: ambiguous option: --python (--python-disable, --python-scan?) I can easily discover options related to python with this :-) And I can type incomplete options, ./waf --python-dis works, for example. Ayway, I am +0.5 for the --python-disable form. But I won't be much upset if we decide to go for --disable-python instead. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 13:20:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 16:20:32 -0400 Subject: [Ns-bugs] [Bug 261] Device MTU and Payload Size Story Half Baked In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=261 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Priority|P3 |P1 Resolution|FIXED | ------- Comment #2 from craigdo at ee.washington.edu 2008-09-05 16:20 ------- Tom requests some semantic changes. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 13:25:38 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 16:25:38 -0400 Subject: [Ns-bugs] [Bug 315] New: MTU Story Not Fully Baked Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=315 Summary: MTU Story Not Fully Baked Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu The MTU and frame size are unconnected in this driver. MTU defaults to very large (unreal) value. Should work similarly to csma with MTU and FrameSize attributes connected via a constant encapsulation mode (PPP). -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 13:28:39 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 16:28:39 -0400 Subject: [Ns-bugs] [Bug 315] MTU Story Not Fully Baked In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=315 ------- Comment #1 from craigdo at ee.washington.edu 2008-09-05 16:28 ------- This is for the point-to-point net device. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 13:29:31 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 16:29:31 -0400 Subject: [Ns-bugs] [Bug 277] star topologies are painful to create In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=277 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 13:29:15 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 16:29:15 -0400 Subject: [Ns-bugs] [Bug 261] Device MTU and Payload Size Story Half Baked In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=261 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu Status|REOPENED |NEW -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 13:29:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 16:29:48 -0400 Subject: [Ns-bugs] [Bug 315] MTU Story Not Fully Baked In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=315 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 15:42:41 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 18:42:41 -0400 Subject: [Ns-bugs] [Bug 302] CSMA Devices should default to DIX not LLC encapsulation. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=302 ------- Comment #2 from craigdo at ee.washington.edu 2008-09-05 18:42 ------- Preliminaries done. Just need to flip the switch and regenerate reference traces. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 16:00:09 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 05 Sep 2008 19:00:09 -0400 Subject: [Ns-bugs] [Bug 302] CSMA Devices should default to DIX not LLC encapsulation. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=302 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 22:56:39 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 01:56:39 -0400 Subject: [Ns-bugs] [Bug 316] New: Build fails on OSX Intel Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 Summary: Build fails on OSX Intel Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu [336/515] cxx: src/internet-stack/nsc-tcp-l4-protocol.cc -> build/debug/src/internet-stack/nsc-tcp-l4-protocol_1.o ../src/internet-stack/nsc-tcp-l4-protocol.cc: In member function 'virtual void ns3::NscTcpL4Protocol::send_callback(const void*, int)': ../src/internet-stack/nsc-tcp-l4-protocol.cc:318: error: invalid application of 'sizeof' to incomplete type 'ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: invalid application of 'sizeof' to incomplete type 'ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:328: error: invalid application of 'sizeof' to incomplete type 'ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:330: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:330: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:330: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:330: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:330: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:330: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:331: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:331: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:331: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:331: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:331: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:331: error: invalid use of undefined type 'const struct ns3::iphdr' ../src/internet-stack/nsc-tcp-l4-protocol.cc:321: error: forward declaration of 'const struct ns3::iphdr' Build failed -> task failed (err #129): [bld:///Users/craigdo/repos/ns-3-dev/src/internet-stack/nsc-tcp-l4-protocol_1.o] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 5 23:02:23 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 02:02:23 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #1 from craigdo at ee.washington.edu 2008-09-06 02:02 ------- i686-apple-darwin9-gcc-4.0.1 Processor Name: Intel Core 2 Duo System Version: Mac OS X 10.5.4 (9E17) Kernel Version: Darwin 9.4.0 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 03:47:25 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 06:47:25 -0400 Subject: [Ns-bugs] [Bug 317] New: build error Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 Summary: build error Product: ns-3 Version: ns-3-dev Platform: PC OS/Version: Windows Status: NEW Severity: critical Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: gavinweng at gmail.com [335/519] cxx: src/internet-stack/nsc-tcp-socket-impl.cc -> build/debug/src/inte rnet-stack/nsc-tcp-socket-impl_1.o ../src/internet-stack/nsc-tcp-socket-impl.cc: In member function `virtual int ns 3::NscTcpSocketImpl::Send(ns3::Ptr, uint32_t)': ../src/internet-stack/nsc-tcp-socket-impl.cc:347: warning: converting of negativ e value `-0x000000001' to `long unsigned int' Build failed -> task failed (err #129): [bld:///cygdrive/d/NS-3/repos/ns-3-dev/src/internet- stack/nsc-tcp-socket-impl_1.o] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 05:11:16 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 08:11:16 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #2 from gjcarneiro at gmail.com 2008-09-06 08:11 ------- /usr/include/netinet/ip.h That is the file that must be different in macosx. It sounds like this header defines incomplete types in macosx. Should a header file from nsc be included instead? If so, from which of the network stacks should it be included? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 06:32:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 09:32:53 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 ------- Comment #4 from gjcarneiro at gmail.com 2008-09-06 09:32 ------- (In reply to comment #2) > I don't think that this bug is fixable. I would like to suggest that we disable > python bindings on cygwin unless the user installs gccxml. Python bindings are disabled now on cygwin. Should we really enable Python bindings if (py)gccxml are installed? They would be arbitrary versions, and in my experience things might easily go wrong if the wrong versions are used. For instance, pygccxml svn trunk works works well with gccxml cvs head, but pygccxml 0.9.5 doesn't work well with gccxml head, only with gccxml cvs from around the date 2008-04-20, neither does pygccxml trunk work well gccxml cvs from 2008-04-20, only with HEAD. At least for NS-3.2 I see no better solution than this: when on CygWin disable python bindings with a warning suggesting the use of MingW in order to get Python bindings on Win32. Anything else sounds too complicated and error prone to work, especially in such a short time frame. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 07:24:31 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 10:24:31 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 ------- Comment #5 from gjcarneiro at gmail.com 2008-09-06 10:24 ------- One problem I forgot with MingW is that it is not compiling atm (bug #296) :-( -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 07:43:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 10:43:49 -0400 Subject: [Ns-bugs] [Bug 296] real time scheduler not compiling in MingW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=296 ------- Comment #5 from gjcarneiro at gmail.com 2008-09-06 10:43 ------- Created an attachment (id=243) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=243&action=view) mingw fix I have code ready to commit that leaves out the real time simulator components if the include file "" is not available. OK to commit? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 07:46:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 10:46:30 -0400 Subject: [Ns-bugs] [Bug 317] build error In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 ------- Comment #1 from gjcarneiro at gmail.com 2008-09-06 10:46 ------- In mingw more problems occur. Maybe it's better to not compile nsc code unconditionally after all? [329/529] cxx: src\internet-stack\nsc-tcp-socket-impl.cc -> build\debug\src\inte rnet-stack\nsc-tcp-socket-impl_1.o ..\src\internet-stack\nsc-tcp-socket-impl.cc:36:24: sys/socket.h: No such file o r directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:37:24: netinet/in.h: No such file o r directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:38:23: arpa/inet.h: No such file or directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:39:24: netinet/ip.h: No such file o r directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:40:25: netinet/tcp.h: No such file or directory ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `virtual int ns 3::NscTcpSocketImpl::Connect(const ns3::Address&)': ..\src\internet-stack\nsc-tcp-socket-impl.cc:310: error: aggregate `ns3::in_addr remoteAddr' has incomplete type and cannot be defined ..\src\internet-stack\nsc-tcp-socket-impl.cc:316: error: `inet_ntoa' was not dec lared in this scope ..\src\internet-stack\nsc-tcp-socket-impl.cc:316: warning: unused variable 'inet _ntoa' ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `virtual int ns 3::NscTcpSocketImpl::Send(ns3::Ptr, uint32_t)': ..\src\internet-stack\nsc-tcp-socket-impl.cc:347: warning: converting of negativ e value `-0x000000001' to `unsigned int' ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `void ns3::NscT cpSocketImpl::CompleteFork()': ..\src\internet-stack\nsc-tcp-socket-impl.cc:500: error: `ntohs' was not declare d in this scope ..\src\internet-stack\nsc-tcp-socket-impl.cc:500: warning: unused variable 'ntoh s' ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `void ns3::NscT cpSocketImpl::ConnectionSucceeded()': ..\src\internet-stack\nsc-tcp-socket-impl.cc:535: error: `ntohs' was not declare d in this scope ..\src\internet-stack\nsc-tcp-socket-impl.cc:535: warning: unused variable 'ntoh s' Build failed -> task failed (err #129): [bld://P:\ns\ns-3-dev\src\internet-stack\nsc-tcp-soc ket-impl_1.o] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 07:47:43 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 10:47:43 -0400 Subject: [Ns-bugs] [Bug 317] build error In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|build system |internet-stack Priority|P3 |P1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 10:20:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 13:20:47 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #3 from fw-ns3 at strlen.de 2008-09-06 13:20 ------- My best guess is that one needs some magic define to get the struct iphdr definition on OSX. Since we don't need to access everything in the ip header, we could use uint32_t[5] instead and avoid including netinet/ip.h completely. I'd rather not include stack specific headers; that might cause a lot of trouble depending on the build OS. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 10:26:35 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 13:26:35 -0400 Subject: [Ns-bugs] [Bug 317] build error In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 fw-ns3 at strlen.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fw-ns3 at strlen.de ------- Comment #2 from fw-ns3 at strlen.de 2008-09-06 13:26 ------- I doubt NSC itself works on mingw (or cygwin, for that matter), so I think we need to blacklist those two. Regarding the src/internet-stack/nsc-tcp-socket-impl.cc:347: warning: converting of error: That looks like a compiler bug to me, why would it need to convert to an unsigned type here? return txEmpty ? p->GetSize () : -1; The method returns int. Does return txEmpty ? (int) p->GetSize () : -1; make things work? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 10:40:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 13:40:49 -0400 Subject: [Ns-bugs] [Bug 296] real time scheduler not compiling in MingW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=296 ------- Comment #6 from craigdo at ee.washington.edu 2008-09-06 13:40 ------- The file (posix process priority and cpu affiniity) really doesn't have anything to do with this, right? The important part is that MinGW apparently doesn't know what a timespec is, right? I'm installing MinGW to see for myself, but if this was the problem, I just checked in some code to not use timespec at all in the case that CLOCK_REALTIME isn't defined. Please check it for me since I cannot yet. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 11:31:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 14:31:48 -0400 Subject: [Ns-bugs] [Bug 296] real time scheduler not compiling in MingW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=296 ------- Comment #7 from gjcarneiro at gmail.com 2008-09-06 14:31 ------- [269/533] cxx: src\simulator\wall-clock-synchronizer.cc -> build\debug\src\simul ator\wall-clock-synchronizer_1.o ..\src\simulator\wall-clock-synchronizer.cc:21:19: sched.h: No such file or dire ctory Build failed -> task failed (err #129): [bld://P:\ns\ns-3-dev\src\simulator\wall-clock-synch ronizer_1.o] About your commit, you can #ifdef out certain methods and the real time scheduler still works? If so, what is the point of having those methods? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 11:37:16 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 14:37:16 -0400 Subject: [Ns-bugs] [Bug 317] build error In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-06 14:37 ------- (In reply to comment #2) > I doubt NSC itself works on mingw (or cygwin, for that matter), so > I think we need to blacklist those two. I am fairly certain that sam made sure that nsc would work on cygwin so disabling it on these platforms would require at least a serious understanding of the problem and being convinced that we can't fix the problems. > Regarding the > src/internet-stack/nsc-tcp-socket-impl.cc:347: warning: converting of > error: That looks like a compiler bug to me, why would it need to convert > to an unsigned type here? > > return txEmpty ? p->GetSize () : -1; I don't know about the code or the error but Packet::GetSize returns an unsigned integer so, the (int) below is probably right. > > The method returns int. > Does > return txEmpty ? (int) p->GetSize () : -1; > > make things work? > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 11:38:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 14:38:49 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-09-06 14:38 ------- (In reply to comment #3) > the ip header, we could use uint32_t[5] instead and avoid including > netinet/ip.h completely. would you care to attach a patch which does this to see what the impact of doing this would be ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 12:17:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 15:17:28 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #5 from fw-ns3 at strlen.de 2008-09-06 15:17 ------- Created an attachment (id=244) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=244&action=view) Do not use struct iphdr -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 15:00:22 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 18:00:22 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #6 from mathieu.lacage at sophia.inria.fr 2008-09-06 18:00 ------- (In reply to comment #5) > Created an attachment (id=244) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=244&action=view) [details] > Do not use struct iphdr ok with me if you add a small comment explaining what you are doing in the code and why :) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 15:00:57 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 18:00:57 -0400 Subject: [Ns-bugs] [Bug 296] real time scheduler not compiling in MingW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=296 ------- Comment #8 from gjcarneiro at gmail.com 2008-09-06 18:00 ------- OK, two more data points: 1. Removing the #include makes the code compile both in mingw and linux. Apparently sched.h is only used for some code inside #if 0 ... #endif. 2. In wall-clock-synchronizer.h you use #ifdef CLOCK_REALTIME. However, since that header file doesn't include won't CLOCK_REALTIME be always undefined (unless by luck whoever includes wall-clock-synchronizer.h had already included time.h first) ? 3. The "#ifdef CLOCK_REALTIME"'ed methods, TimespecToNs and TimespecAdd are protected and currently unused, so I reiterate my suggestion to remove them completely; they are causing portability problems and have no use. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 15:07:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 18:07:45 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #7 from gjcarneiro at gmail.com 2008-09-06 18:07 ------- Any objections to making nsc glue code conditionally compiled again? MingW will never compile again without this change. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 15:12:37 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 18:12:37 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #8 from mathieu.lacage at sophia.inria.fr 2008-09-06 18:12 ------- (In reply to comment #7) > Any objections to making nsc glue code conditionally compiled again? MingW > will never compile again without this change. > Why can't mingw compile this code ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 15:21:46 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 18:21:46 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #9 from gjcarneiro at gmail.com 2008-09-06 18:21 ------- (In reply to comment #8) > (In reply to comment #7) > Why can't mingw compile this code ? No unix socket headers: [333/533] cxx: src\internet-stack\nsc-tcp-socket-impl.cc -> build\debug\src\inte rnet-stack\nsc-tcp-socket-impl_1.o ..\src\internet-stack\nsc-tcp-socket-impl.cc:36:24: sys/socket.h: No such file o r directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:37:24: netinet/in.h: No such file o r directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:38:23: arpa/inet.h: No such file or directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:39:24: netinet/ip.h: No such file o r directory ..\src\internet-stack\nsc-tcp-socket-impl.cc:40:25: netinet/tcp.h: No such file or directory ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `virtual int ns 3::NscTcpSocketImpl::Connect(const ns3::Address&)': ..\src\internet-stack\nsc-tcp-socket-impl.cc:310: error: aggregate `ns3::in_addr remoteAddr' has incomplete type and cannot be defined ..\src\internet-stack\nsc-tcp-socket-impl.cc:316: error: `inet_ntoa' was not dec lared in this scope ..\src\internet-stack\nsc-tcp-socket-impl.cc:316: warning: unused variable 'inet _ntoa' ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `virtual int ns 3::NscTcpSocketImpl::Send(ns3::Ptr, uint32_t)': ..\src\internet-stack\nsc-tcp-socket-impl.cc:347: warning: converting of negativ e value `-0x000000001' to `unsigned int' ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `void ns3::NscT cpSocketImpl::CompleteFork()': ..\src\internet-stack\nsc-tcp-socket-impl.cc:500: error: `ntohs' was not declare d in this scope ..\src\internet-stack\nsc-tcp-socket-impl.cc:500: warning: unused variable 'ntoh s' ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `void ns3::NscT cpSocketImpl::ConnectionSucceeded()': ..\src\internet-stack\nsc-tcp-socket-impl.cc:535: error: `ntohs' was not declare d in this scope ..\src\internet-stack\nsc-tcp-socket-impl.cc:535: warning: unused variable 'ntoh s' Build failed -> task failed (err #129): [bld://P:\ns\ns-3-dev\src\internet-stack\nsc-tcp-soc ket-impl_1.o] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 16:28:14 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 06 Sep 2008 19:28:14 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #10 from fw-ns3 at strlen.de 2008-09-06 19:28 ------- Created an attachment (id=245) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=245&action=view) Rip out all socket includes Gustavo, could you please try this patch? Thanks. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 21:27:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 00:27:28 -0400 Subject: [Ns-bugs] [Bug 296] real time scheduler not compiling in MingW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=296 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #9 from craigdo at ee.washington.edu 2008-09-07 00:27 ------- Removed the high resolution clocks since the expected use case did not materialize. Verified builds correctly on MinGW-5.1.4 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 6 23:16:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 02:16:21 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 ------- Comment #9 from liujatp at gmail.com 2008-09-07 02:16 ------- i know what has happend after reading kernel code. when getsockname() was called without bind(), linux kernel fill the struct sockaddr with the initial value(memset with zero), then it call move_addr_to_user() to fill the userspace sockaddr by the input namelen. so, if the input namelen == 0, the output sockaddr not changed, if the input namelen == sizeof(sockaddr), the output sockaddr were all zero, if the input namelen (0, sizeof(sockaddr)), the output sockaddr partly zero, partly not changed. At the NS3 side, GetSockName return address value by 0, when called before bind(). (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Created an attachment (id=237) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=237&action=view) [details] [details] [details] > > > Socket::GetSockName patch > > > > > > thanks methieu's comments, i did some test calling getsockname before bind, the > > > output sockaddr was same to the input. > > > > can you show me the code you used to test this ? > > And the reason I am asking this is that I wrote the following code and it shows > that getsockname does not return the the input address: it returns ip=0.0.0.0, > port=0, and family = AF_INET > > #include > #include > #include > > int main (int argc, char *argv[]) > { > struct sockaddr_in name; > socklen_t namelen; > int fd = socket (AF_INET, SOCK_STREAM, 0); > > namelen = sizeof (struct sockaddr); > name.sin_family = 0xff; > name.sin_port = 0xffff; > name.sin_addr.s_addr = 0xffffffff; > int retval = getsockname (fd, (struct sockaddr *)&name, &namelen); > > if (name.sin_family != AF_INET) > { > printf ("family error\n"); > } > printf ("port=%d\n", name.sin_port); > printf ("ad=%d\n", name.sin_addr.s_addr); > > return 0; > } > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 00:31:59 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 03:31:59 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 ------- Comment #10 from liujatp at gmail.com 2008-09-07 03:31 ------- my test code: int main() { int sockfd, ret; struct sockaddr_in addr, addr2; socklen_t len = 0; if ((sockfd = socket(AF_INET,SOCK_STREAM,0)) == -1) { printf("socket creat error\n"); } memset(&addr, 0, sizeof(addr)); len = 6;//different value, different sockaddr output addr.sin_family = AF_INET; addr.sin_port = htons(8001); addr.sin_addr.s_addr = inet_addr("127.0.0.1"); addr2.sin_port = 0xffff; addr2.sin_addr.s_addr = 0xffffffff; #if 0 if (bind(sockfd, (struct sockaddr*)&addr, sizeof(addr)) == -1) { printf("bind error %d\n", errno); } #endif ret = getsockname(sockfd, (struct sockaddr*)&addr2, &len); if (ret == -1) { printf("getsockname error %d\n", errno); } printf("addr.sin_family = %d, len = %d, addr->sin_port = %d, addr= %s\n", addr2.sin_family, len, htons(addr2.sin_port), inet_ntoa(addr2.sin_addr.s_addr)); } (In reply to comment #9) > i know what has happend after reading kernel code. > when getsockname() was called without bind(), linux kernel fill the struct > sockaddr with the initial value(memset with zero), then it call > move_addr_to_user() to fill the userspace sockaddr by the input namelen. > so, > if the input namelen == 0, the output sockaddr not changed, > if the input namelen == sizeof(sockaddr), the output sockaddr were all zero, > if the input namelen (0, sizeof(sockaddr)), the output sockaddr partly zero, > partly not changed. > > At the NS3 side, GetSockName return address value by 0, when called before > bind(). > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 07:02:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 10:02:45 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #11 from gjcarneiro at gmail.com 2008-09-07 10:02 ------- After your patch the compilation errors in that file were reduced to a single one, I think it was reported already: [333/533] cxx: src\internet-stack\nsc-tcp-socket-impl.cc -> build\debug\src\inte rnet-stack\nsc-tcp-socket-impl_1.o ..\src\internet-stack\nsc-tcp-socket-impl.cc: In member function `virtual int ns 3::NscTcpSocketImpl::Send(ns3::Ptr, uint32_t)': ..\src\internet-stack\nsc-tcp-socket-impl.cc:345: warning: converting of negativ e value `-0x000000001' to `unsigned int' Build failed This patch fixes that error: diff -r 00938a81ad10 src/internet-stack/nsc-tcp-socket-impl.cc --- a/src/internet-stack/nsc-tcp-socket-impl.cc Sat Sep 06 21:15:59 2008 -0700 +++ b/src/internet-stack/nsc-tcp-socket-impl.cc Sun Sep 07 15:00:49 2008 +0100 @@ -344,7 +342,14 @@ { if (m_errno == ERROR_AGAIN) { - return txEmpty ? p->GetSize () : -1; + if (txEmpty) + { + return p->GetSize (); + } + else + { + return -1; + } } if (txEmpty) { But then I get more errors when compiling the next source file: [334/533] cxx: src\internet-stack\nsc-tcp-l4-protocol.cc -> build\debug\src\inte rnet-stack\nsc-tcp-l4-protocol_1.o ..\src\internet-stack\nsc-tcp-l4-protocol.cc:39:19: dlfcn.h: No such file or dir ectory ..\src\internet-stack\nsc-tcp-l4-protocol.cc: In destructor `virtual ns3::NscTcp L4Protocol::~NscTcpL4Protocol()': ..\src\internet-stack\nsc-tcp-l4-protocol.cc:93: error: `dlclose' was not declar ed in this scope ..\src\internet-stack\nsc-tcp-l4-protocol.cc:93: warning: unused variable 'dlclo se' ..\src\internet-stack\nsc-tcp-l4-protocol.cc: In member function `void ns3::NscT cpL4Protocol::SetNscLibrary(const std::string&)': ..\src\internet-stack\nsc-tcp-l4-protocol.cc:100: error: `RTLD_NOW' was not decl ared in this scope ..\src\internet-stack\nsc-tcp-l4-protocol.cc:100: error: `dlopen' was not declar ed in this scope ..\src\internet-stack\nsc-tcp-l4-protocol.cc:102: error: `dlerror' was not decla red in this scope ..\src\internet-stack\nsc-tcp-l4-protocol.cc:102: warning: unused variable 'dler ror' ..\src\internet-stack\nsc-tcp-l4-protocol.cc:100: warning: unused variable 'RTLD _NOW' ..\src\internet-stack\nsc-tcp-l4-protocol.cc:100: warning: unused variable 'dlop en' ..\src\internet-stack\nsc-tcp-l4-protocol.cc: In member function `void ns3::NscT cpL4Protocol::SetNode(ns3::Ptr)': ..\src\internet-stack\nsc-tcp-l4-protocol.cc:117: error: `dlsym' was not declare d in this scope ..\src\internet-stack\nsc-tcp-l4-protocol.cc:117: warning: unused variable 'dlsy m' Build failed -> task failed (err #129): [bld://P:\ns\ns-3-dev\src\internet-stack\nsc-tcp-l4- protocol_1.o] Naturally, dlopen and friends are not available in MinGW. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 07:04:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 10:04:42 -0400 Subject: [Ns-bugs] [Bug 317] build error In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 ------- Comment #4 from gjcarneiro at gmail.com 2008-09-07 10:04 ------- (In reply to comment #0) > [335/519] cxx: src/internet-stack/nsc-tcp-socket-impl.cc -> > build/debug/src/inte > rnet-stack/nsc-tcp-socket-impl_1.o > ../src/internet-stack/nsc-tcp-socket-impl.cc: In member function `virtual int > ns > 3::NscTcpSocketImpl::Send(ns3::Ptr, uint32_t)': > ../src/internet-stack/nsc-tcp-socket-impl.cc:347: warning: converting of > negativ > e value `-0x000000001' to `long unsigned int' > Build failed > -> task failed (err #129): > [bld:///cygdrive/d/NS-3/repos/ns-3-dev/src/internet- > stack/nsc-tcp-socket-impl_1.o] > I posted a patch to fix this in bug #316. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 07:32:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 10:32:42 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #12 from gjcarneiro at gmail.com 2008-09-07 10:32 ------- By the way, the patch is not sound: - m_remotePort = ntohs(port); + m_remotePort = nsc_bytswap_16 (port); ntohs is _not_ a simple byte swap. It only swaps bytes on little endian architectures. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 07:59:01 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 10:59:01 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #13 from mathieu.lacage at sophia.inria.fr 2008-09-07 10:59 ------- (In reply to comment #12) > By the way, the patch is not sound: > > - m_remotePort = ntohs(port); > + m_remotePort = nsc_bytswap_16 (port); > > ntohs is _not_ a simple byte swap. It only swaps bytes on little endian > architectures. no, it is safe. It is just suboptimal because it will use shifts and masks to access a value when it could just read it. > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 08:39:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 11:39:21 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #14 from gjcarneiro at gmail.com 2008-09-07 11:39 ------- (In reply to comment #13) > (In reply to comment #12) > > By the way, the patch is not sound: > > > > - m_remotePort = ntohs(port); > > + m_remotePort = nsc_bytswap_16 (port); > > > > ntohs is _not_ a simple byte swap. It only swaps bytes on little endian > > architectures. > > no, it is safe. It is just suboptimal because it will use shifts and masks to > access a value when it could just read it. It's safe? I must be missing something. Clearly ntohs and nsc_bytswap_16 yield different results in x86 and PowerPC? Are you saying the code is safe even on PowerPC, or that you don't expect it to be used on PowerPC systems? Well, we could say that, if ntohs swaps bytes and htons also swaps, then the system will be self-consistent as long as no packet is transmitted to another computer. However, even then things will appear wrong if you capture packets to pcap file and display them in wireshark. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 09:23:43 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 12:23:43 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #15 from fw-ns3 at strlen.de 2008-09-07 12:23 ------- Gustavo is right wrt. the byteswap. I shouldn't churn out patches without thinking. To make some progress here: Since dlopen() isn't available anyway, its pointless to try to make this work by removing the socket includes. So, I vote for the following: - Revert 3635:cddd59578812 ('compile nsc code unconditionally.') - Apply 'Do not use struct iphdr' patch to fix OSX build. Perhaps we should also 'blacklist' mingw so --enable-nsc prints an error message? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 09:28:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 12:28:34 -0400 Subject: [Ns-bugs] [Bug 306] nsc: -ldl dependency problem In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #3 from tomh at tomh.org 2008-09-07 12:28 ------- This bug seems to have crept back in: machine: ns-regression (gcc-4.2.3 Ubuntu x86) [496/536] cxx_link: build/debug/samples/main-callback_2.o -> build/debug/samples/main-callback debug/libns3.so: undefined reference to `dlopen' debug/libns3.so: undefined reference to `dlclose' debug/libns3.so: undefined reference to `dlerror' debug/libns3.so: undefined reference to `dlsym' collect2: ld returned 1 exit status -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 10:01:46 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 13:01:46 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #16 from gjcarneiro at gmail.com 2008-09-07 13:01 ------- (In reply to comment #15) > Gustavo is right wrt. the byteswap. I shouldn't churn out patches without > thinking. > To make some progress here: > Since dlopen() isn't available anyway, its pointless to try to make this > work by removing the socket includes. So, I vote for the following: > - Revert 3635:cddd59578812 ('compile nsc code unconditionally.') > - Apply 'Do not use struct iphdr' patch to fix OSX build. > > Perhaps we should also 'blacklist' mingw so --enable-nsc prints an error > message? > It's not impossible to support the equivalent of dlopen in mingw, using win32 API: http://msdn.microsoft.com/en-us/library/ms682599(VS.85).aspx But I think developing this for MingW so close to NS 3.2 is risky, and besides does NSC itself even compile in MingW? If not, I don't see the point on NS-3 supporting NSC in MingW. I am +1 for leaving nsc glue code compiled in by default, but only if the needed header files are available on the system. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 10:47:59 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 13:47:59 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #17 from mathieu.lacage at sophia.inria.fr 2008-09-07 13:47 ------- (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > By the way, the patch is not sound: > > > > > > - m_remotePort = ntohs(port); > > > + m_remotePort = nsc_bytswap_16 (port); > > > > > > ntohs is _not_ a simple byte swap. It only swaps bytes on little endian > > > architectures. > > > > no, it is safe. It is just suboptimal because it will use shifts and masks to > > access a value when it could just read it. > > It's safe? I must be missing something. Clearly ntohs and nsc_bytswap_16 ok, you are right: I misread the code. However, looking at this patch carefully, I noticed that it looks like getpeername seems to return a port number _in network byte order_. Is this is true ? If so, this is utterly broken ! -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 10:54:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 13:54:45 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #18 from mathieu.lacage at sophia.inria.fr 2008-09-07 13:54 ------- (In reply to comment #15) > Gustavo is right wrt. the byteswap. I shouldn't churn out patches without > thinking. > To make some progress here: > Since dlopen() isn't available anyway, its pointless to try to make this > work by removing the socket includes. So, I vote for the following: > - Revert 3635:cddd59578812 ('compile nsc code unconditionally.') Rather than revert that patchset (which added the sim_* headers in the src/internet-stack directory per sam's suggestion), I would like to apply the attached patch. > - Apply 'Do not use struct iphdr' patch to fix OSX build. > > Perhaps we should also 'blacklist' mingw so --enable-nsc prints an error > message? yes, please. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 10:55:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 13:55:32 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #19 from mathieu.lacage at sophia.inria.fr 2008-09-07 13:55 ------- Created an attachment (id=246) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=246&action=view) make nsc compilation conditional again to support mingwin. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 10:57:24 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 13:57:24 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #20 from mathieu.lacage at sophia.inria.fr 2008-09-07 13:57 ------- (From update of attachment 246) this patch is untested (no build machine available right now) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 11:10:05 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 14:10:05 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #21 from fw-ns3 at strlen.de 2008-09-07 14:10 ------- (In reply to comment #17) > ok, you are right: I misread the code. However, looking at this patch > carefully, I noticed that it looks like getpeername seems to return a port > number _in network byte order_. Is this is true ? If so, this is utterly > broken ! Sigh. This originally used a struct sockaddr*, just like the system call of the same name, until i realized that struct sockaddr is different depending on the stack. The port number is whats stored in sockaddr_in->sin_port, which is in network byte order. PLEASE PLEASE PLEASE don't use this bug entry to (rightfully) yell at me for coming up with a crap API, do so on the mailing list so we can create a saner NSC API. (and for the record, I agree that having it in nb order is just stupid.) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 13:16:18 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 16:16:18 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #22 from mathieu.lacage at sophia.inria.fr 2008-09-07 16:16 ------- (In reply to comment #21) > which is in network byte order. > > PLEASE PLEASE PLEASE don't use this bug entry to (rightfully) yell at me for > coming up with a crap API, do so on the mailing list so we can create a saner > NSC API. ok, I will. I merely pointed this out because if it was in host order, we would not be having this discussion about ntohs :) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 14:37:23 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 17:37:23 -0400 Subject: [Ns-bugs] [Bug 318] New: real-time sim causes linking errors in mingw Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 Summary: real-time sim causes linking errors in mingw Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com I would rather just disable the real-time simulator feature on mingw... debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns317RealtimeEv entLock4LockEv': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:68: undefined r eference to `ns3::SystemMutex::Lock()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns317RealtimeEv entLock6UnlockEv': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:74: undefined r eference to `ns3::SystemMutex::Unlock()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImplC2Ev': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:78: undefined r eference to `ns3::SystemMutex::SystemMutex()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:98: undefined r eference to `ns3::SystemMutex::~SystemMutex()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImplC1Ev': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:78: undefined r eference to `ns3::SystemMutex::SystemMutex()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:98: undefined r eference to `ns3::SystemMutex::~SystemMutex()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImplD2Ev': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:111: undefined reference to `ns3::SystemMutex::~SystemMutex()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:111: undefined reference to `ns3::SystemMutex::~SystemMutex()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImplD1Ev': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:111: undefined reference to `ns3::SystemMutex::~SystemMutex()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:111: undefined reference to `ns3::SystemMutex::~SystemMutex()' debug\src\simulator\realtime-simulator-impl_1.o:P:/ns/ns-3-dev/build/../src/simu lator/realtime-simulator-impl.cc:111: more undefined references to `ns3::SystemM utex::~SystemMutex()' follow debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl12SetSchedulerENS_3PtrINS_9SchedulerEEE': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:145: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:155: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:155: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl15ProcessOneEventEv': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:202: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:232: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:232: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:307: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:313: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:313: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZNK3ns321RealtimeS imulatorImpl10IsFinishedEv': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:362: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:363: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:363: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl3RunEv': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:407: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:426: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:426: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:443: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:445: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:445: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl8ScheduleERKNS_8TimeUnitILi1EEERKNS_3PtrINS_9EventImplEEE': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:575: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:589: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:589: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl11ScheduleNowERKNS_3PtrINS_9EventImplEEE': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:601: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:608: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:608: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl15ScheduleDestroyERKNS_3PtrINS_9EventImplEEE': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:621: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:630: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:630: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZN3ns321RealtimeSi mulatorImpl6RemoveERKNS_7EventIdE': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:681: undefined reference to `ns3::CriticalSection::CriticalSection(ns3::SystemMutex&)' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:686: undefined reference to `ns3::CriticalSection::~CriticalSection()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:686: undefined reference to `ns3::CriticalSection::~CriticalSection()' debug\src\simulator\realtime-simulator-impl_1.o: In function `ZnwjPv': P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:(.text$_ZN3ns31 7RealtimeEventLockD1Ev[ns3::RealtimeEventLock::~RealtimeEventLock()]+0x4f): unde fined reference to `ns3::SystemMutex::~SystemMutex()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:(.text$_ZN3ns31 7RealtimeEventLockC1Ev[ns3::RealtimeEventLock::RealtimeEventLock()]+0x5a): undef ined reference to `ns3::SystemMutex::SystemMutex()' P:/ns/ns-3-dev/build/../src/simulator/realtime-simulator-impl.cc:(.text$_ZN3ns31 7RealtimeEventLockD0Ev[ns3::RealtimeEventLock::~RealtimeEventLock()]+0x4f): unde fined reference to `ns3::SystemMutex::~SystemMutex()' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizerC2Ev': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:32: undefined r eference to `ns3::SystemCondition::SystemCondition()' P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:67: undefined r eference to `ns3::SystemCondition::~SystemCondition()' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizerC1Ev': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:32: undefined r eference to `ns3::SystemCondition::SystemCondition()' P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:67: undefined r eference to `ns3::SystemCondition::~SystemCondition()' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizerD2Ev': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:73: undefined r eference to `ns3::SystemCondition::~SystemCondition()' P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:73: undefined r eference to `ns3::SystemCondition::~SystemCondition()' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizerD1Ev': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:73: undefined r eference to `ns3::SystemCondition::~SystemCondition()' P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:73: undefined r eference to `ns3::SystemCondition::~SystemCondition()' debug\src\simulator\wall-clock-synchronizer_1.o:P:/ns/ns-3-dev/build/../src/simu lator/wall-clock-synchronizer.cc:73: more undefined references to `ns3::SystemCo ndition::~SystemCondition()' follow debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizer8DoSignalEv': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:269: undefined reference to `ns3::SystemCondition::SetCondition(bool)' P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:270: undefined reference to `ns3::SystemCondition::Signal()' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizer14DoSetConditionEb': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:277: undefined reference to `ns3::SystemCondition::SetCondition(bool)' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizer8SpinWaitEy': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:313: undefined reference to `ns3::SystemCondition::GetCondition()' debug\src\simulator\wall-clock-synchronizer_1.o: In function `ZN3ns321WallClockS ynchronizer9SleepWaitEy': P:/ns/ns-3-dev/build/../src/simulator/wall-clock-synchronizer.cc:345: undefined reference to `ns3::SystemCondition::TimedWait(unsigned long long)' collect2: ld returned 1 exit status Build failed -> task failed (err #129): [bld://P:\ns\ns-3-dev\libns3.dll] -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 14:39:06 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 17:39:06 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 ------- Comment #23 from gjcarneiro at gmail.com 2008-09-07 17:39 ------- (In reply to comment #20) > (From update of attachment 246 [details]) > this patch is untested (no build machine available right now) The patch works fine on mingw. Build doesn't complete, but that's due to a different problem, reported as bug #318. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 20:02:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 23:02:07 -0400 Subject: [Ns-bugs] [Bug 318] real-time sim causes linking errors in mingw In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 ------- Comment #1 from craigdo at ee.washington.edu 2008-09-07 23:02 ------- > I would rather just disable the real-time simulator feature on mingw... This isn't due to the real-time simulator, it is due to the fact that the threading primitives checked in several months ago are not being compiled since the platform is "win32" not "unix." The real-time simulator just uses them. If this is turned on, then I believe MinGW will break since there are no pthreads. I think the real question is, "should MinGW be turned off." Perhaps our windows story should be that we can user virtual machines ... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 20:55:41 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 23:55:41 -0400 Subject: [Ns-bugs] [Bug 318] real-time sim causes linking errors in mingw In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 ------- Comment #2 from tomh at tomh.org 2008-09-07 23:55 ------- (In reply to comment #1) > > I would rather just disable the real-time simulator feature on mingw... > > This isn't due to the real-time simulator, it is due to the fact that the > threading primitives checked in several months ago are not being compiled since > the platform is "win32" not "unix." The real-time simulator just uses them. > > If this is turned on, then I believe MinGW will break since there are no > pthreads. > > I think the real question is, "should MinGW be turned off." Perhaps our > windows story should be that we can user virtual machines ... > I think our Windows story should be that we continue to make the core simulator work with Windows, but features that require a lot of work to support or are unreasonable are either unsupported or supported by a Windows maintainer. As you point out, there are free virtualization options nowadays for Windows users. Historically, I have been surprised by the number of ns-2 Cygwin users; hence, I would be reluctant to drop Cygwin/mingw altogether unless/until we get feedback that most of those users are happy moving to virtual machines. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 20:57:44 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 07 Sep 2008 23:57:44 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 ------- Comment #6 from tomh at tomh.org 2008-09-07 23:57 ------- (In reply to comment #4) > (In reply to comment #2) > > I don't think that this bug is fixable. I would like to suggest that we disable > > python bindings on cygwin unless the user installs gccxml. > > Python bindings are disabled now on cygwin. > > Should we really enable Python bindings if (py)gccxml are installed? They > would be arbitrary versions, and in my experience things might easily go wrong > if the wrong versions are used. For instance, pygccxml svn trunk works works > well with gccxml cvs head, but pygccxml 0.9.5 doesn't work well with gccxml > head, only with gccxml cvs from around the date 2008-04-20, neither does > pygccxml trunk work well gccxml cvs from 2008-04-20, only with HEAD. > > At least for NS-3.2 I see no better solution than this: when on CygWin disable > python bindings with a warning suggesting the use of MingW in order to get > Python bindings on Win32. Anything else sounds too complicated and error prone > to work, especially in such a short time frame. I would be fine with this. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 21:02:00 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 00:02:00 -0400 Subject: [Ns-bugs] [Bug 318] real-time sim causes linking errors in mingw In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 ------- Comment #3 from tomh at tomh.org 2008-09-08 00:01 ------- (In reply to comment #2) > (In reply to comment #1) > > > I would rather just disable the real-time simulator feature on mingw... > > > > This isn't due to the real-time simulator, it is due to the fact that the > > threading primitives checked in several months ago are not being compiled since > > the platform is "win32" not "unix." The real-time simulator just uses them. > > > > If this is turned on, then I believe MinGW will break since there are no > > pthreads. > > > > I think the real question is, "should MinGW be turned off." Perhaps our > > windows story should be that we can user virtual machines ... > > > > I think our Windows story should be that we continue to make the core simulator > work with Windows, and to be clear, I don't view that real-time simulator has to be considered as part of the core simulator in this case (although technically it is part of src/simulator), since it is a specialized scheduler for use in emulation and packet-emitting modes that are not going to be easy to support in Windows anyways. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 21:15:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 00:15:48 -0400 Subject: [Ns-bugs] [Bug 318] real-time sim causes linking errors in mingw In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 ------- Comment #4 from craigdo at ee.washington.edu 2008-09-08 00:15 ------- > > I think our Windows story should be that we continue to make > > the core simulator work with Windows, > > and to be clear, I don't view that real-time simulator has to > be considered as part of the core simulator in this case > (although technically it is part of src/simulator), since it > is a specialized scheduler for use in emulation and packet- > emitting modes that are not going to be easy to support in > Windows anyways. While I agree with this (and I turned off the real-time simulator build in the case where the underlying primitives are not available) the question now is what exactly do we mean by core simulator. For example, the real-time simulator works fine on cygwin, but not on MinGw. What this seems to mean is that we need to come up with a product matrix defining what is supported on what kind of machine and teach waf to respect it. We need to publish this matrix so that, for example, folks that need to do emulation or packet-emitting modes should use cygwin and not MinGW. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 21:58:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 00:58:17 -0400 Subject: [Ns-bugs] [Bug 318] real-time sim causes linking errors in mingw In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 ------- Comment #5 from tomh at tomh.org 2008-09-08 00:58 ------- (In reply to comment #4) > > > I think our Windows story should be that we continue to make > > > the core simulator work with Windows, > > > > and to be clear, I don't view that real-time simulator has to > > be considered as part of the core simulator in this case > > (although technically it is part of src/simulator), since it > > is a specialized scheduler for use in emulation and packet- > > emitting modes that are not going to be easy to support in > > Windows anyways. > > While I agree with this (and I turned off the real-time simulator build in the > case where the underlying primitives are not available) the question now is > what exactly do we mean by core simulator. For example, the real-time > simulator works fine on cygwin, but not on MinGw. > > What this seems to mean is that we need to come up with a product matrix > defining what is supported on what kind of machine and teach waf to respect it. > We need to publish this matrix so that, for example, folks that need to do > emulation or packet-emitting modes should use cygwin and not MinGW. Yes I totally agree the time has come for this type of documentation. However, I hope to not burden Gustavo and waf too much in dealing with the various combinations, and we will need to also get the regression scripts to cover the valid ones and avoid the invalid ones. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 7 23:57:57 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 02:57:57 -0400 Subject: [Ns-bugs] [Bug 319] New: Regession failure in test: test-wifi-wired-bridging Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=319 Summary: Regession failure in test: test-wifi-wired-bridging Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu Fails on ns-test at least. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 02:49:10 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 05:49:10 -0400 Subject: [Ns-bugs] [Bug 318] system mutex APIs missing in mingw, linking errors In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker OS/Version|All |Windows Summary|real-time sim causes linking|system mutex APIs missing in |errors in mingw |mingw, linking errors ------- Comment #6 from gjcarneiro at gmail.com 2008-09-08 05:49 ------- Re-titling for more accurate description. Actually I would be more in favor of excluding features based on missing header files or libraries rather than on a black list of platforms. This is the perfect example why. Normally people don't have pthread.h in mingw. However, there is an open source pthread implementation out there [1] that makes it easy to install a pthread library and header. Black lists are often the wrong solution, configuration tests are better. [1] http://sourceware.org/pthreads-win32/ -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 04:39:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 07:39:21 -0400 Subject: [Ns-bugs] [Bug 318] system mutex APIs missing in mingw, linking errors In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=318 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #7 from gjcarneiro at gmail.com 2008-09-08 07:39 ------- (In reply to comment #6) > Re-titling for more accurate description. > > Actually I would be more in favor of excluding features based on missing header > files or libraries rather than on a black list of platforms. I committed this change now. I'll revert if someone objects. With this commit plus Mathieu's NSC disabling patch (bug #316) makes the whole thing compile and run unit tests in mingw. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 06:37:16 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 09:37:16 -0400 Subject: [Ns-bugs] [Bug 306] nsc: -ldl dependency problem when GtkConfigStore disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|nsc: -ldl dependency |nsc: -ldl dependency |problem |problem when GtkConfigStore | |disabled ------- Comment #4 from tomh at tomh.org 2008-09-08 09:37 ------- (changing title to reflect new information) This can be repeated by forcibly disabling gtk-config-store from the build (I didn't see a waf option) and gtk.h won't get pulled in. It can be solved by installing or enabling gtk-config-store. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 06:44:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 09:44:04 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails: test wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |craigdo at ee.washington.edu ------- Comment #5 from tomh at tomh.org 2008-09-08 09:44 ------- *** Bug 319 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 06:44:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 09:44:04 -0400 Subject: [Ns-bugs] [Bug 319] Regession failure in test: test-wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=319 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #1 from tomh at tomh.org 2008-09-08 09:44 ------- *** This bug has been marked as a duplicate of bug 313 *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 06:43:36 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 09:43:36 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails: test wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|regression test fails |regression test fails: test | |wifi-wired-bridging ------- Comment #4 from tomh at tomh.org 2008-09-08 09:43 ------- I noticed this error seems to raise when gcc-4.2.3 machine is used. ns-regression is one of these now (can be used to reproduce this). -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 08:40:36 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 11:40:36 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails: test wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 ------- Comment #6 from raj.b at gatech.edu 2008-09-08 11:40 ------- I also get a regression failure on this same test on x86, Mac OS 10.4.11, gcc 4.0.1, Darwin 8.11.1 The pcap files generated on Mac are different than the ones I posted from my other machine (x86 Ubuntu, Linux 2.6.24, gcc 4.2.3) AND different from the reference traces. Attachments coming. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 08:47:10 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 11:47:10 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails: test wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 ------- Comment #7 from raj.b at gatech.edu 2008-09-08 11:47 ------- Created an attachment (id=247) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=247&action=view) tarball of the traces generated -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 09:23:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 12:23:53 -0400 Subject: [Ns-bugs] [Bug 316] Build fails on OSX Intel In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=316 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #24 from mathieu.lacage at sophia.inria.fr 2008-09-08 12:23 ------- applied conditional nsc patch. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 09:34:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 12:34:30 -0400 Subject: [Ns-bugs] [Bug 314] NSC support wscript changes appear buggy In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=314 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #6 from mathieu.lacage at sophia.inria.fr 2008-09-08 12:34 ------- all this has been fixed. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 09:38:05 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 12:38:05 -0400 Subject: [Ns-bugs] [Bug 306] nsc: -ldl dependency problem when GtkConfigStore disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-08 12:38 ------- I can't reproduce this with any gcc I tried it on. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 10:47:10 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 13:47:10 -0400 Subject: [Ns-bugs] [Bug 322] --enable-nsc attempts to use mercurial to download nsc unconditionally. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=322 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 10:47:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 13:47:04 -0400 Subject: [Ns-bugs] [Bug 322] New: --enable-nsc attempts to use mercurial to download nsc unconditionally. Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=322 Summary: --enable-nsc attempts to use mercurial to download nsc unconditionally. Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr it should probably try to download http://research.wand.net.nz/software/nsc/nsc-0.4.0.tar.bz2 in release mode. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 10:53:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 13:53:11 -0400 Subject: [Ns-bugs] [Bug 322] --enable-nsc attempts to use mercurial to download nsc unconditionally. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=322 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-08 13:53 ------- The issue is also that, if I download nsc by hand and if I try --enable-nsc, the script will try to use mercurial anyway to update the repo which is likely to fail :/ -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 11:29:08 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 14:29:08 -0400 Subject: [Ns-bugs] [Bug 317] build error In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=317 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-08 14:29 ------- this bug is fixed now. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 11:40:50 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 14:40:50 -0400 Subject: [Ns-bugs] [Bug 297] Python Binding Compilation error with Cygwin In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=297 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #7 from mathieu.lacage at sophia.inria.fr 2008-09-08 14:40 ------- this bug is fixed now too: we disable python on cygwin. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 11:58:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 14:58:42 -0400 Subject: [Ns-bugs] [Bug 323] New: waf --valgrind doesn't check for valgrind first Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=323 Summary: waf --valgrind doesn't check for valgrind first Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu "waf --valgrind stuff" produces a cryptic python error along the lines of "file not found" when valgrind isn't present on the system. It would be nice if waf configure could check for valgrind, and in the case that it isn't found, "waf --valgrind stuff" could produce an output message like "--valgrind option is disabled since valgrind was not found on this system", and then either fail, or run "stuff" anyway without valgrind. I suspect --doxygen is the same way, but can't verify, and that is a separate bug report anyway. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 12:42:06 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 15:42:06 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails: test wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 ------- Comment #8 from craigdo at ee.washington.edu 2008-09-08 15:42 ------- This regression test crashes on cygwin ... ~/repos/ns-3-dev > ./waf --regression Entering directory `/home/owner/repos/ns-3-dev/build' Compilation finished successfully ========== Running Regression Tests ========== Synchronizing reference traces using Mercurial. Cloning http://code.nsnam.org/ns-3-dev-ref-traces from repo. Done. PASS test-csma-broadcast PASS test-csma-multicast PASS test-csma-one-subnet PASS test-csma-packet-socket PASS test-realtime-udp-echo PASS test-simple-error-model PASS test-simple-global-routing PASS test-simple-point-to-point-olsr PASS test-tcp-large-transfer PASS test-udp-echo 45 [main] wifi-wired-bridging 42556 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Command ['/home/owner/repos/ns-3-dev/build/debug/examples/wifi-wired-bridging.exe', '--SendIp=0'] exited with code -11 ~/repos/ns-3-dev > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 14:00:13 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 17:00:13 -0400 Subject: [Ns-bugs] [Bug 324] New: Regression tests refuse to run under MinGW Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=324 Summary: Regression tests refuse to run under MinGW Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu The regression tests (as a whole) refuse to run under MinGW + MSYS 1.0: The system cannot find the path specified. bzip2: (stdin) is not a bzip2 file. tar: Child returned status 2 tar: Error exit delayed from previous errors Entering directory `C:\msys\1.0\home\owner\repos\ns-3-dev\build' Compilation finished successfully ========== Running Regression Tests ========== Retrieving ns-3-dev-ref-traces.tar.bz2 from web. Done. Reference traces directory does not exist -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 14:55:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 17:55:21 -0400 Subject: [Ns-bugs] [Bug 313] regression test fails: test wifi-wired-bridging In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=313 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #9 from mathieu.lacage at sophia.inria.fr 2008-09-08 17:55 ------- fixed now. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 14:56:05 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 17:56:05 -0400 Subject: [Ns-bugs] [Bug 324] Regression tests refuse to run under MinGW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=324 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-08 17:56 ------- I vote to make that not a P1 because mingw is not a platform we support. wouldbenicetofix though. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 15:11:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 18:11:34 -0400 Subject: [Ns-bugs] [Bug 324] Regression tests refuse to run under MinGW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=324 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-08 18:11 ------- PATH=$PATH:/c/Python25 should work -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 15:29:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 18:29:03 -0400 Subject: [Ns-bugs] [Bug 324] Regression tests refuse to run under MinGW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=324 ------- Comment #3 from craigdo at ee.washington.edu 2008-09-08 18:29 ------- > PATH=$PATH:/c/Python25 I had the paths set up already. The problem revolves around the return code from hg version which wscript uses to see if Mercurial is available. There is no ns-3-dev-ref-traces.tar.bz2 in the releases directory since ns-3-dev is expected to use hg, so the contents of the tar file is the text of a 404 error. I can fake the system out by manually cloning the reference traces repo, but then the realtime-udp-echo regression test asserts, and other regression tests report errors. I am very tired of MinGW. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 16:11:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 19:11:55 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 ------- Comment #11 from mathieu.lacage at sophia.inria.fr 2008-09-08 19:11 ------- (In reply to comment #9) > i know what has happend after reading kernel code. > when getsockname() was called without bind(), linux kernel fill the struct > sockaddr with the initial value(memset with zero), then it call > move_addr_to_user() to fill the userspace sockaddr by the input namelen. > so, > if the input namelen == 0, the output sockaddr not changed, > if the input namelen == sizeof(sockaddr), the output sockaddr were all zero, > if the input namelen (0, sizeof(sockaddr)), the output sockaddr partly zero, > partly not changed. yes. > > At the NS3 side, GetSockName return address value by 0, when called before > bind(). > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 16:18:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 19:18:42 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 ------- Comment #12 from mathieu.lacage at sophia.inria.fr 2008-09-08 19:18 ------- > > At the NS3 side, GetSockName return address value by 0, when called before > > bind(). The problem with your latest patch is the same as before: GetSockName must do more than just return 0. It should also change the content of the Address variable to contain what the linux version returns, that is, an InetSocketAddress with the right initial values. i.e., for example: the right code for TcpSocketImpl: // make sure local variables are initialized during construction TcpSocketImpl::TcpSocketImpl () : m_localAddress (Ipv4Address::GetAny ()), m_localPort (0) {} int TcpSocketImpl::GetSockName (Address &address) { address = InetSocketAddress (m_localAddress, m_localPort); return 0; } Please, update your patch accordingly for UdpSocket and check that you do something similar for PacketSocket. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 8 20:29:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 08 Sep 2008 23:29:32 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 ------- Comment #13 from liujatp at gmail.com 2008-09-08 23:29 ------- mathieu, i can not push an attachment here::internal error.. (i had sent you by mail) (In reply to comment #12) > > > At the NS3 side, GetSockName return address value by 0, when called before > > > bind(). > > The problem with your latest patch is the same as before: GetSockName must do > more than just return 0. It should also change the content of the Address > variable to contain what the linux version returns, that is, an > InetSocketAddress with the right initial values. > > i.e., for example: the right code for TcpSocketImpl: > > // make sure local variables are initialized during construction > TcpSocketImpl::TcpSocketImpl () > : m_localAddress (Ipv4Address::GetAny ()), > m_localPort (0) > {} > int > TcpSocketImpl::GetSockName (Address &address) > { > address = InetSocketAddress (m_localAddress, m_localPort); > return 0; > } > > Please, update your patch accordingly for UdpSocket and check that you do > something similar for PacketSocket. > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 00:37:43 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 03:37:43 -0400 Subject: [Ns-bugs] [Bug 306] nsc: -ldl dependency problem when GtkConfigStore disabled In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=306 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Comment #6 from tomh at tomh.org 2008-09-09 03:37 ------- I couldn't reproduce again tonight, so it must have been fixed sometime today. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 09:25:46 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 12:25:46 -0400 Subject: [Ns-bugs] [Bug 325] New: regression code should be moved into regression/wscript Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=325 Summary: regression code should be moved into regression/wscript Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr the top-level script is a bit too big to manage. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 09:30:54 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 12:30:54 -0400 Subject: [Ns-bugs] [Bug 326] New: ./waf --regression should not exist Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=326 Summary: ./waf --regression should not exist Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr instead, the regressions should be run from waf check -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 10:14:51 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 13:14:51 -0400 Subject: [Ns-bugs] [Bug 324] Regression tests refuse to run under MinGW In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=324 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 10:16:38 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 13:16:38 -0400 Subject: [Ns-bugs] [Bug 326] ./waf --regression should not exist In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=326 ------- Comment #1 from raj.b at gatech.edu 2008-09-09 13:16 ------- The regressions take quite a while to run, and what if I want JUST the unit tests and not the regressions, or vice versa? Perhaps we could keep --regression, add a --unit-tests (which does what "check" does now), and have "check" simply run both unit tests and regressions. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 10:16:44 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 13:16:44 -0400 Subject: [Ns-bugs] [Bug 322] --enable-nsc attempts to use mercurial to download nsc unconditionally. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=322 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-09 13:16 ------- changeset e10e48cbce9c -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 12:44:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 15:44:07 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #237 is|0 |1 obsolete| | ------- Comment #14 from mathieu.lacage at sophia.inria.fr 2008-09-09 15:44 ------- Created an attachment (id=248) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=248&action=view) patch by liu -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 12:44:44 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 15:44:44 -0400 Subject: [Ns-bugs] [Bug 283] getsockname implementation needs support in socket base class In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=283 ------- Comment #15 from mathieu.lacage at sophia.inria.fr 2008-09-09 15:44 ------- (In reply to comment #14) > Created an attachment (id=248) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=248&action=view) [details] > patch by liu > latest patch looks good to me. Please, commit _after_ ns-3.2 is released. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 16:58:10 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 19:58:10 -0400 Subject: [Ns-bugs] [Bug 327] New: need 'conditional' regression tests Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=327 Summary: need 'conditional' regression tests Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr we need to pass the waf 'env' from the waf configury down to the regression test functions in regression/tests/*.py to allow tests to not do anything when they detect they should not run -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 9 17:38:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 09 Sep 2008 20:38:45 -0400 Subject: [Ns-bugs] [Bug 328] New: NSC Doesn't symlink linux-2.6.18.so Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=328 Summary: NSC Doesn't symlink linux-2.6.18.so Product: ns-3 Version: ns-3-dev Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu There is a bug in src/internet-stack/wscript, the result of which is that liblinux-2.6.18 is not symlinked in the build dir. Example tcp-nsc-zoo asserts. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 03:05:16 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 06:05:16 -0400 Subject: [Ns-bugs] [Bug 329] New: pcap files generated in native win32 (mingw) are always corrupt Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=329 Summary: pcap files generated in native win32 (mingw) are always corrupt Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com Like the summary says. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 03:13:22 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 06:13:22 -0400 Subject: [Ns-bugs] [Bug 329] pcap files generated in native win32 (mingw) are always corrupt In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=329 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |Windows ------- Comment #1 from gjcarneiro at gmail.com 2008-09-10 06:13 ------- wireshark says: "The capture file appears to be damaged or corrupt. (pcap: File has 36569088-byte packet, bigger than maximum of 65535)". There's a bugzilla installation problem and I cannot attach the file. It is at: http://telecom.inescporto.pt/~gjc/csma-broadcast-0-0.pcap -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 04:34:36 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 07:34:36 -0400 Subject: [Ns-bugs] [Bug 328] NSC Doesn't symlink linux-2.6.18.so In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=328 fw-ns3 at strlen.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from fw-ns3 at strlen.de 2008-09-10 07:34 ------- The code that was to set up this sym link got moved outside of the for loop that iterates over the list of stacks, so it only created the link for the last entry... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 06:49:15 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 09:49:15 -0400 Subject: [Ns-bugs] [Bug 327] need 'conditional' regression tests In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=327 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #1 from gjcarneiro at gmail.com 2008-09-10 09:49 ------- Do you really think they need the whole env? Why not just a list of enabled 'features', like I am doing with the Python bindings? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 06:57:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 09:57:04 -0400 Subject: [Ns-bugs] [Bug 326] ./waf --regression should not exist In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=326 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #2 from gjcarneiro at gmail.com 2008-09-10 09:57 ------- (In reply to comment #0) > instead, the regressions should be run from waf check -1 Regression tests require network access, can take long to run, and are crude. Besides, you can run both regression and unit tests with ./waf check --regression. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 07:26:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 10:26:53 -0400 Subject: [Ns-bugs] [Bug 330] New: Avoid using the external 'diff' command for regression testing Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=330 Summary: Avoid using the external 'diff' command for regression testing Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com I just realized Python has builtin modules for comparing files, and so we could do diff'ing using only pure Python code: http://docs.python.org/lib/module-filecmp.html http://docs.python.org/lib/module-difflib.html With some Python love, the trailing carriage return problem could be worked around. Additionally, with no need for 'diff' it would be easier on MinGW users (no need to install MSys). I will work on this some day "in the future", post-3.2. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 07:28:37 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 10:28:37 -0400 Subject: [Ns-bugs] [Bug 330] Avoid using the external 'diff' command for regression testing In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=330 ------- Comment #1 from gjcarneiro at gmail.com 2008-09-10 10:28 ------- Note to self, an additional refactoring needed is to move the check for mercurial presence into the configure stage. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 07:50:26 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 10:50:26 -0400 Subject: [Ns-bugs] [Bug 331] New: Shouldn't the method Packet::PeekHeader be const? Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=331 Summary: Shouldn't the method Packet::PeekHeader be const? Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com Marking as P1 due to potential API impact. /** * Deserialize but does _not_ remove the header from the internal buffer. * This method invokes Header::Deserialize. * * \param header a reference to the header to read from the internal buffer. * \returns the number of bytes read from the packet. */ uint32_t PeekHeader (Header &header); It sounds like the method does not modify the packet in any way. If so, why is not const? This has impact since most our trace callbacks now receive const packets, and packet->Copy ()->PeekHeader (header) seems kind of silly. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 08:44:00 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 11:44:00 -0400 Subject: [Ns-bugs] [Bug 331] Shouldn't the method Packet::PeekHeader be const? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=331 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-10 11:43 ------- I don't consider that to be a P1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 08:45:05 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 11:45:05 -0400 Subject: [Ns-bugs] [Bug 327] need 'conditional' regression tests In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=327 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-10 11:45 ------- (In reply to comment #1) > Do you really think they need the whole env? Why not just a list of enabled > 'features', like I am doing with the Python bindings? > it seems easier to just pass down everything but it's your call. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 08:48:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 11:48:17 -0400 Subject: [Ns-bugs] [Bug 331] Shouldn't the method Packet::PeekHeader be const? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=331 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P2 ------- Comment #2 from gjcarneiro at gmail.com 2008-09-10 11:48 ------- I was thinking if it was trivial to fix it would be nice to include it in 3.2, that's all. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 11:22:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 14:22:17 -0400 Subject: [Ns-bugs] [Bug 332] New: SocketIpTtlTag should not be a tag Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=332 Summary: SocketIpTtlTag should not be a tag Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: node module AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr This should be an attribute on the socket instead to mimick the IP_TTL socket option. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 12:15:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 15:15:04 -0400 Subject: [Ns-bugs] [Bug 333] does not seem to respect distance changes In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=333 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 12:14:56 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 15:14:56 -0400 Subject: [Ns-bugs] [Bug 333] New: does not seem to respect distance changes Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=333 Summary: does not seem to respect distance changes Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: wifi AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr i.e., packets seem to always be transmitted successfully, despite distance changes. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 12:36:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 15:36:11 -0400 Subject: [Ns-bugs] [Bug 332] SocketIpTtlTag should not be a tag In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=332 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-10 15:36 ------- or maybe we need both. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 14:14:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 17:14:28 -0400 Subject: [Ns-bugs] [Bug 335] New: ./waf --regression no longer works without mercurial present Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 Summary: ./waf --regression no longer works without mercurial present Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu regression should download traces from web, not crash [craig-dowells-imac] ~/tests/ns-3.2-RC2 > ./waf --regression Entering directory `/Users/craigdo/tests/ns-3.2-RC2/build' Compilation finished successfully ========== Running Regression Tests ========== Traceback (most recent call last): File "./waf", line 141, in Scripting.prepare() File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 207, in prepare main() File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 299, in main if fun:fun() File "/Users/craigdo/tests/ns-3.2-RC2/wscript", line 448, in shutdown run_regression() File "/Users/craigdo/tests/ns-3.2-RC2/wscript", line 911, in run_regression if subprocess.Popen(["hg", "version"], stdout=dev_null(), stderr=dev_null()).wait() == 0: File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/pproc.py", line 123, in __init__ self._execute_child(args,executable,preexec_fn,close_fds,cwd,env,universal_newlines,startupinfo,creationflags,shell,p2cread,p2cwrite,c2pread,c2pwrite,errread,errwrite) File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/pproc.py", line 424, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory [craig-dowells-imac] ~/tests/ns-3.2-RC2 > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 14:56:25 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 17:56:25 -0400 Subject: [Ns-bugs] [Bug 336] New: optimized build doesn't compile Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 Summary: optimized build doesn't compile Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu In ns-3-dev AND the RC2 tarball. Platform: x86 Ubuntu 8.10 (Intrepid Ibex) alpha 5, gcc4.3.2 Configured as: ./waf configure --enable-nsc -d optimized Warning generated: [223/539] cxx: src/core/random-variable.cc -> build/optimized/src/core/random-variable_1.o cc1plus: warnings being treated as errors ../src/core/random-variable.cc: In static member function ?static void ns3::RandomVariableBase::GetRandomSeeds(uint32_t*)?: ../src/core/random-variable.cc:199: error: ignoring return value of ?ssize_t read(int, void*, size_t)?, declared with attribute warn_unused_result I think this can be fixed by using something other than the low level read call. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 15:14:27 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 18:14:27 -0400 Subject: [Ns-bugs] [Bug 332] SocketIpTtlTag should not be a tag In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=332 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-10 18:14 ------- bah, we already have the requested attribute. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 16:21:26 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 19:21:26 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 17:18:19 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 20:18:19 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|optimized build doesn't |optimized build doesn't |compile |compile on Ubuntu 8.10 ------- Comment #1 from craigdo at ee.washington.edu 2008-09-10 20:18 ------- The optimized build does work on ns-regression and OSX Intel. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 10 20:06:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 10 Sep 2008 23:06:34 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-10 23:06 ------- (In reply to comment #0) > In ns-3-dev AND the RC2 tarball. > > Platform: x86 Ubuntu 8.10 (Intrepid Ibex) alpha 5, gcc4.3.2 > > Configured as: > ./waf configure --enable-nsc -d optimized > > Warning generated: > [223/539] cxx: src/core/random-variable.cc -> > build/optimized/src/core/random-variable_1.o > cc1plus: warnings being treated as errors > ../src/core/random-variable.cc: In static member function ?static void > ns3::RandomVariableBase::GetRandomSeeds(uint32_t*)?: > ../src/core/random-variable.cc:199: error: ignoring return value of ?ssize_t > read(int, void*, size_t)?, declared with attribute warn_unused_result > > I think this can be fixed by using something other than the low level read > call. An even easier way to fix this warning would be to actually check that you have read what you expected. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 06:52:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 09:52:17 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from gjcarneiro at gmail.com 2008-09-11 09:52 ------- Should be fixed by rev. 3677. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 07:13:46 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 10:13:46 -0400 Subject: [Ns-bugs] [Bug 327] need 'conditional' regression tests In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=327 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #3 from gjcarneiro at gmail.com 2008-09-11 10:13 ------- It's done. The waf environment is available as the 'env' variable of the 'tracediff' pseudo-module. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 07:22:00 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 10:22:00 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #3 from gjcarneiro at gmail.com 2008-09-11 10:21 ------- changeset: 3678:3a4021da265d -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 07:38:26 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 10:38:26 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 raj.b at gatech.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #4 from raj.b at gatech.edu 2008-09-11 10:38 ------- Nope, in opt builds, NS_ASSERT is replaced with whitespace, so: [223/539] cxx: src/core/random-variable.cc -> build/optimized/src/core/random-variable_1.o cc1plus: warnings being treated as errors ../src/core/random-variable.cc: In static member function ?static void ns3::RandomVariableBase::GetRandomSeeds(uint32_t*)?: ../src/core/random-variable.cc:199: error: unused variable ?bytes_read? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 07:42:29 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 10:42:29 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 ------- Comment #5 from raj.b at gatech.edu 2008-09-11 10:42 ------- One solution is to conditionally FATAL_ERROR out if somehow the read from /dev/random fails. diff -r 3a4021da265d src/core/random-variable.cc --- a/src/core/random-variable.cc Thu Sep 11 15:21:19 2008 +0100 +++ b/src/core/random-variable.cc Thu Sep 11 10:41:46 2008 -0400 @@ -198,7 +198,10 @@ { ssize_t bytes_read = read (RandomVariableBase::devRandom, &seeds[i], sizeof (seeds[i])); - NS_ASSERT (bytes_read == sizeof (seeds[i])); + if (bytes_read != sizeof (seeds[i])) + { + NS_FATAL_ERROR ("Read from /dev/random failed"); + } } if (RngStream::CheckSeed(seeds)) break; // Got a valid one } -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 08:26:13 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 11:26:13 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #1 from raj.b at gatech.edu 2008-09-11 11:26 ------- Created an attachment (id=251) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=251&action=view) fix If there is no comment I will push by the end of the day. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 08:25:13 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 11:25:13 -0400 Subject: [Ns-bugs] [Bug 337] New: opt build fails in address.cc on Ubuntu 8.10 Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 Summary: opt build fails in address.cc on Ubuntu 8.10 Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: node module AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu x86 Ubuntu 8.10 alpha 5 cc1plus: warnings being treated as errors In function ?void* memset(void*, int, size_t)?, inlined from ?ns3::Address::Address()? at ../src/node/address.cc:13: /usr/include/bits/string3.h:82: error: call to ?__warn_memset_zero_len? declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters In function ?void* memset(void*, int, size_t)?, inlined from ?ns3::Address::Address()? at ../src/node/address.cc:13: /usr/include/bits/string3.h:82: error: call to ?__warn_memset_zero_len? declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters Since this memset says "fill in the first zero bytes with the value zero", it does absolutely nothing, so the fix is to remove that line. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 08:33:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 11:33:17 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-11 11:33 ------- Looking carefully at the code, there is something obviously wrong with it. For example, the following is completely braindead and there are many instances of it. memset (m_data, 0, m_len); memcpy (m_data, buffer, m_len); So, there is something fishy in this code (and yes, it's all mine so, it's all my fault) and we need to look at it carefully rather than just get rid of the compiler warning mindlessly. We should figure out what was the intent of the code. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 08:49:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 11:49:21 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #3 from craigdo at ee.washington.edu 2008-09-11 11:49 ------- This has the "signature" of a replace-string or sed type of error. It seems that the memset is trying to clear the data buffer and the memcpy is trying to copy the new (possibly fewer) bits in. Now, memset (m_data, 0, sizeof(m_data)); memcpy (m_data, buffer, m_len); would make a whole lot more sense. As Mathieu observes, though, was something else going on, or did sizeof(m_data) or the equivalent just get caught up in a sed script? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 09:01:50 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 12:01:50 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #4 from raj.b at gatech.edu 2008-09-11 12:01 ------- It looks like copy-paste type of error to me. Maybe you started by trying to enforce a good practice of initializing all of your memory (which was fine when m_len > 0 and you have no data to copy). Then the cases came up where you DID have data to copy, and a few copy and pastes later, that practice becomes erroneous and we have the current code. The alternative to the "just get rid of the compiler warning" solution then is remove all of these superfluous memsets. Craig I'm not sure I follow your comment...isn't sizeof(m_data) always a constant, the size of a pointer on your architecture (probably 4 bytes)? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 09:05:42 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 12:05:42 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #5 from raj.b at gatech.edu 2008-09-11 12:05 ------- Scratch that last comment Craig, I had a brain fart :-) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 09:07:29 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 12:07:29 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #6 from mathieu.lacage at sophia.inria.fr 2008-09-11 12:07 ------- (In reply to comment #3) > memset (m_data, 0, sizeof(m_data)); > memcpy (m_data, buffer, m_len); I had something similar in mind with sizeof (m_data) replaced with MAX_LEN but I have not spent enough time looking at the code to figure out whether it would make sense. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 09:18:27 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 12:18:27 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #7 from craigdo at ee.washington.edu 2008-09-11 12:18 ------- Heh, I can see myself making exactly this error very clearly. Given, NS_ASSERT (m_len <= MAX_SIZE); memset (m_data, 0, sizeof(m_data)); memcpy (m_data, address.m_data, m_len); I might think to myself, why use sizeof(m_data) when I use MAX_SIZE on the line before. I'll just change it to make it clearer. s/sizeof(m_data)/ *ring* *ring* [conversation about buffer overflows and lengths] Where was I? Oh, about m_len and and that sizeof ... s/sizeof(m_data)/m_len/g :-) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 09:54:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 12:54:48 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 09:54:39 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 12:54:39 -0400 Subject: [Ns-bugs] [Bug 336] optimized build doesn't compile on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=336 ------- Comment #6 from mathieu.lacage at sophia.inria.fr 2008-09-11 12:54 ------- (In reply to comment #5) > One solution is to conditionally FATAL_ERROR out if somehow the read from > /dev/random fails. > > diff -r 3a4021da265d src/core/random-variable.cc > --- a/src/core/random-variable.cc Thu Sep 11 15:21:19 2008 +0100 > +++ b/src/core/random-variable.cc Thu Sep 11 10:41:46 2008 -0400 > @@ -198,7 +198,10 @@ > { > ssize_t bytes_read = read (RandomVariableBase::devRandom, > &seeds[i], sizeof (seeds[i])); > - NS_ASSERT (bytes_read == sizeof (seeds[i])); > + if (bytes_read != sizeof (seeds[i])) > + { > + NS_FATAL_ERROR ("Read from /dev/random failed"); > + } > } > if (RngStream::CheckSeed(seeds)) break; // Got a valid one > } Pushed this. changeset 07fdb67e52bb -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 11:10:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 14:10:07 -0400 Subject: [Ns-bugs] [Bug 333] does not seem to respect distance changes In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=333 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-11 14:10 ------- changeset d3c79037d422 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 13:56:05 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 16:56:05 -0400 Subject: [Ns-bugs] [Bug 114] global routing doesn't handle multi-hop layer-2 subnets In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=114 ------- Comment #2 from tomh at tomh.org 2008-09-11 16:56 ------- Created an attachment (id=252) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=252&action=view) test case program this is an example program that should work with global routing but doesn't yet will fix for ns-3.3 but document the limitation in ns-3.2 as a "known issue" -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 14:05:43 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 17:05:43 -0400 Subject: [Ns-bugs] [Bug 114] global routing doesn't handle multi-hop layer-2 subnets In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=114 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ns-bugs at isi.edu AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu ------- Comment #3 from tomh at tomh.org 2008-09-11 17:05 ------- we discussed this last Friday. There likely is new API necessary for a NetDevice to make this work: NetDevice::IsBridge(). Basically, the global routing code crawls the network, link-by-link. If it encounters a bridge node, it will first encounter a NetDevice type that is a real interface (such as CSMA). It needs to determine whether the CSMA interface is part of a bridge group and, if so, find all of the bridged-together NetDevices and recursively crawl each of those channels looking for more NetDevices in the same broadcast domain. If there is a NetDevice::IsBridge() method, the code can iterate the devices on a target node and look for bridge devices. For each bridge device found, it can iterate and look whether the device in question is part of that bridge group. A more direct way would be to ask the target device (i.e., the CSMA interface) whether it is itself part of a bridge group (e.g., NetDevice::IsBridged() -note the trailing "d") but that would require devices to know whether they are in a bridge or not and is not strictly required to make this global routing work. So, we agreed to try for a solution that would add NetDevice::IsBridge() and set it to true for any device that considers itself a bridge. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 14:07:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 17:07:03 -0400 Subject: [Ns-bugs] [Bug 114] global routing doesn't handle multi-hop layer-2 subnets In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=114 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal ------- Comment #4 from tomh at tomh.org 2008-09-11 17:07 ------- bump from enhancement to normal, since we now have bridging code that needs this functionality -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 14:08:19 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 17:08:19 -0400 Subject: [Ns-bugs] [Bug 338] New: MTU calculations can't handle overflows Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=338 Summary: MTU calculations can't handle overflows Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu The MTU and FrameSize calcualtions use 16-bit arithmetic and can't handle cases where crazies want to set MTU to 0xffff. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 14:10:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 17:10:17 -0400 Subject: [Ns-bugs] [Bug 326] ./waf --regression should not exist In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=326 ------- Comment #3 from tomh at tomh.org 2008-09-11 17:10 ------- I agree with previous comments against this suggestion. I was just in a situation today where I wanted to run waf check but I had no network access. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 15:32:27 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 18:32:27 -0400 Subject: [Ns-bugs] [Bug 338] MTU calculations can't handle overflows In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=338 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 15:56:40 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 18:56:40 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #8 from craigdo at ee.washington.edu 2008-09-11 18:56 ------- The underlying issue is that the code in address.cc has redundant bit sets and has done this since the beginning of time (wrt this file). However it is generally harmless. The new GCC optimizer in 4.3.2 as configured by Ubuntu 8.10 seems to try and optimize one of the cases out and complains that it doesn't make sense to try and zero out zero bytes (which it doesn't). At this point, however, the cost/benefit analysis may tend to recommend that it is more risky to change it now and possibly uncover other strange dependencies than to try and make the optimizations turned on in alpha 5 of Ubuntu Insane Ibix work (vanill GCC 4.3.2 does work fine according to ML). We can chance it, or we can turn this bug down to P3 and add a release note saying that there is an optimized build issue with Ubuntu 8.10 After all of the recent chaos, I tend to agree with ML -- turn it down to P3 and don't take any more chances. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 19:21:25 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 22:21:25 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #9 from raj.b at gatech.edu 2008-09-11 22:21 ------- (In reply to comment #8) > The underlying issue is that the code in address.cc has redundant bit sets and > has done this since the beginning of time (wrt this file). However it is > generally harmless. The new GCC optimizer in 4.3.2 as configured by Ubuntu > 8.10 seems to try and optimize one of the cases out and complains that it > doesn't make sense to try and zero out zero bytes (which it doesn't). > Yes, something like this. Upon looking into the Ubuntu string.h header, there is in fact an additional warning attribute that says something along the lines of "check to make sure parameter such and such is not zero". I haven't looked, but I am guessing that other implementations don't have this warning, and I'm at a loss for why only opt builds trigger the warning... > At this point, however, the cost/benefit analysis may tend to recommend that it > is more risky to change it now and possibly uncover other strange dependencies > than to try and make the optimizations turned on in alpha 5 of Ubuntu Insane > Ibix work (vanill GCC 4.3.2 does work fine according to ML). I would think that if we somehow broke the Address class, we would see all sorts of changes in our traces, i.e. regression failures. The code as written is also clearly redundant but harmless. That said... > We can chance it, or we can turn this bug down to P3 and add a release note > saying that there is an optimized build issue with Ubuntu 8.10 > > After all of the recent chaos, I tend to agree with ML -- turn it down to P3 > and don't take any more chances. > I would be fine with this, provided the issue is fixed before ns-2.3. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 11 19:23:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 11 Sep 2008 22:23:21 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 ------- Comment #10 from raj.b at gatech.edu 2008-09-11 22:23 ------- erm, ns-3.3 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 03:12:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 06:12:34 -0400 Subject: [Ns-bugs] [Bug 339] New: Unconditional assert API proposed Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 Summary: Unconditional assert API proposed Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com Looking at the common error that I made in bug 336, which Mathieu post-fixed thus: > - NS_ASSERT (bytes_read == sizeof (seeds[i])); > + if (bytes_read != sizeof (seeds[i])) > + { > + NS_FATAL_ERROR ("Read from /dev/random failed"); > + } I wonder why we do not have a macro NS_ASSERT_UNCOND (condition) which is not removed in optimized builds. #define NS_ASSERT_UNCOND(condition) if (!(condition)) { std::cerr << "Assertion `" << #condition << "' failed. Aborting." << std::endl; } It is certainly not _needed_, but it is very _convenient_. Just an idea... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 07:52:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 10:52:30 -0400 Subject: [Ns-bugs] [Bug 339] Unconditional assert API proposed In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 ------- Comment #1 from raj.b at gatech.edu 2008-09-12 10:52 ------- I like this idea, but I would suggest calling this a conditional fatal error, not an unconditional assertion. That is, something like #define NS_FATAL_ERROR_COND(predicate, msg). Note that this would simplify almost every usage (if not _every_ usage) of NS_FATAL_ERROR, since it almost always falls in an "if" block. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 08:03:59 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 11:03:59 -0400 Subject: [Ns-bugs] [Bug 339] Unconditional assert API proposed In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 ------- Comment #2 from gjcarneiro at gmail.com 2008-09-12 11:03 ------- To be honest I don't like NS_FATAL_ERROR_COND. ssize_t result = read (sock, &foo, N); NS_FATAL_ERROR_COND (result != N, "short read"); To me NS_FATAL_ERROR_COND makes it look like normally it produces a fatal error; not aborting feels like the exception and not the rule. Additionally, normally it is easier to specify the condition in terms of what is the expected value, rather than what values are wrong. For comparison, my original idea was: ssize_t result = read (sock, &foo, N); NS_ASSERT_UNCOND (result == N); One non obvious advantage is that it makes it easy to "upgrade" the importance of an existing assertion once the developer realizes the error check has negligible impact on performance and the error is extremely serious. Just my 0.02 ?. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 09:39:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 12:39:21 -0400 Subject: [Ns-bugs] [Bug 339] Unconditional assert API proposed In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 ------- Comment #3 from craigdo at ee.washington.edu 2008-09-12 12:39 ------- Assertions are designed to provide a way to check for internal program consistency. They derive from Meyer's pre- and post-condition checks. They can be compiled out for efficiency, so you never, never put any functionality in an assert, just like you never, never put any functionality in a debug statement. It's an error to do so. Having an ASSERT_UNCOND seems to blur the distinction between consistency checks and errors. Since there the idiom is, if (cond) NS_FATAL_ERROR, then it makes sense to encapsulate that in a macro to make life easier. If I were starting from scratch, I'd make an NS_ASSERT (cond) and a matching NS_FATAL_ERROR (cond) and then add an NS_ASSERT_MSG (cond, msg) and a matching NS_FATAL_ERROR_MSG (cond, msg). There are 80 instances of NS_FATAL_ERROR (msg) now, though. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 09:46:26 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 12:46:26 -0400 Subject: [Ns-bugs] [Bug 339] Unconditional assert API proposed In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 ------- Comment #4 from gjcarneiro at gmail.com 2008-09-12 12:46 ------- (In reply to comment #3) [...] > There are 80 instances of NS_FATAL_ERROR (msg) now, though. _Please_ I beg you, do not even consider to change NS_FATAL_ERROR. Blasphemy! No more gratuitous API breakage please :| How about NS_ABORT_IF (condition, message) ? I don't think you can't get a much more explicit name than that... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 10:11:16 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 13:11:16 -0400 Subject: [Ns-bugs] [Bug 339] Unconditional assert API proposed In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 ------- Comment #5 from raj.b at gatech.edu 2008-09-12 13:11 ------- (In reply to comment #4) > (In reply to comment #3) > [...] > > There are 80 instances of NS_FATAL_ERROR (msg) now, though. > > _Please_ I beg you, do not even consider to change NS_FATAL_ERROR. Blasphemy! > No more gratuitous API breakage please :| > > How about NS_ABORT_IF (condition, message) ? I don't think you can't get a > much more explicit name than that... > The fatal error and assert macros are for developer use, completely internally to the ns-3 codebase. Why are you concerned with API breakage here? I'd be surpised if a "user" even knew these macros existed. It would however be some sed work to change things. +1 to Craig's suggestion, for inclusion in ns-3.3 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 10:34:18 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 13:34:18 -0400 Subject: [Ns-bugs] [Bug 339] Unconditional assert API proposed In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=339 ------- Comment #6 from gjcarneiro at gmail.com 2008-09-12 13:34 ------- For me _all_ API in ns3/*.h is public. This is the type of thing that makes me want to stick to NS 3.2 for a very long time. I don't know why I care about API breakage anymore; I guess it's just reflex reaction :P -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 10:49:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 13:49:47 -0400 Subject: [Ns-bugs] [Bug 337] opt build fails in address.cc on Ubuntu 8.10 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=337 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 ------- Comment #11 from craigdo at ee.washington.edu 2008-09-12 13:49 ------- Fix in 3.3 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 10:52:36 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 13:52:36 -0400 Subject: [Ns-bugs] [Bug 340] New: OnOff crashes if Stop() is called without Start() having been called before Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=340 Summary: OnOff crashes if Stop() is called without Start() having been called before Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: applications AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com 145 void OnOffApplication::StopApplication() // Called at time specified by Stop 146 { 147 NS_LOG_FUNCTION_NOARGS (); 148 149 CancelEvents (); 150 m_socket->Close (); 151 } If the application hasn't started, m_socket is NULL. Maybe it's better to add an assert, not sure. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:19:39 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:19:39 -0400 Subject: [Ns-bugs] [Bug 341] New: Get unexpected dropped packets when using SetSendCallback with heavy traffic Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 Summary: Get unexpected dropped packets when using SetSendCallback with heavy traffic Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: evensky at dancer.ca.sandia.gov I have a test program that when run as: ./p2p_test --size=10 .... 0ns: node1: InjectPacket(0x7fff3dcf93f0,1000000000ns,A,10) 0ns: node1:inject frag:Payload (size=10) 10:A{10} ... 1000000000ns: node1: SendPacket(0x7fff3dcf93f0,0x6363b0) 1000000000ns: node1:forwarding:Payload (size=10) 10:A{10} .... Send returned 0 1000000959ns: node2: HandleRead(0x7fff3dcf9370,0x635f10) 1000000959ns: node2:recv:Payload (size=10) left{0} 10:A{10} 1000000959ns: node2: Packet Delivered but when I use evensky at waltz:~/tools/networks/ns3toys/layer2$ ./p2p_test --size=10000000 ... 1000000000ns: node1: SendPacket(0x7fffd9059750,0x63c9d0) 1000000000ns: node1:forwarding:Payload (size=50000)50000:A{50000} m_socket{0x635450}->Send(packet): sock= 0x635450 Send returned 0 1000000000ns: node1: SendPacket(0x7fffd9059750,0x63cad0) 1000000000ns: node1:forwarding:Payload (size=50000)50000:A{50000} m_socket{0x635450}->Send(packet): sock= 0x635450 Send returned -1 ... and it doesn't print out that the whole packet was delivered. It seems to fail for size = 5050001 >./p2p_test --size=5050000|fgrep -e '-1' >./p2p_test --size=5050001|fgrep -e '-1' Send returned -1 Test program is attached. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:28:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:28:55 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #1 from evensky at dancer.ca.sandia.gov 2008-09-12 14:28 ------- Created an attachment (id=253) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=253&action=view) sends data via PacketSocket from one node to another This doesn't have the cleanest output, but I wanted to get it out. If its too hard to read, I can work on that. What it does is take a user specified size for a data stream and break it into FragSize (50000 bytes for ease of use) packets and sends that to the receiver. The receiver prints out the packets it gets and decrements a byte count that main set. When the count hits zero it prints out that the packet has been delivered. This should be the last thing printed. If USE_HANDLESEND is defined, then we set a SendCallback in the sender. I try to only send whole packets to make life a little easier. This test program generates the same output if USE_HANDLESEND is not defined. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:42:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:42:07 -0400 Subject: [Ns-bugs] [Bug 342] New: ns-3.2 release regression should not depend on mercurial Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=342 Summary: ns-3.2 release regression should not depend on mercurial Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: regression AssignedTo: craigdo at ee.washington.edu ReportedBy: tomh at tomh.org CC: ns-bugs at isi.edu I suggest this as a P1 bug for the release. the released version requires mercurial to fetch trace repositories and fails when mercurial is not installed. IMO, one of two things is needed for ease of use: 1) release traces are included in the released version 2) wget instead of mercurial is used to fetch the release tarball Option 1) would make the ns-3 release 2MB instead of 1MB, but would work without any network access. At this point in the project, I think option 1) would be worth the extra file size, to improve user experience across the board. In the future, if regression traces swell, we can move to wget. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:48:13 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:48:13 -0400 Subject: [Ns-bugs] [Bug 343] New: utils/bench-packets is broken and asserts Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=343 Summary: utils/bench-packets is broken and asserts Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: general AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu It looks like this benchmark utility tries to run tests with and without metadata, which became disallowed at some point (here I think http://code.nsnam.org/ns-3-dev/rev/648048bca501). So it appears that this utility wasn't run in the past year by anyone on the team...this begs the question of why do we have these utilities? Perhaps they should be part of our validation, either check or regression or something else? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:53:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:53:47 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #2 from craigdo at ee.washington.edu 2008-09-12 14:53 ------- I just built a new release and this still happens. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:54:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:54:48 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomh at tomh.org ------- Comment #3 from craigdo at ee.washington.edu 2008-09-12 14:54 ------- *** Bug 342 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:54:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:54:48 -0400 Subject: [Ns-bugs] [Bug 342] ns-3.2 release regression should not depend on mercurial In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=342 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #1 from craigdo at ee.washington.edu 2008-09-12 14:54 ------- *** This bug has been marked as a duplicate of bug 335 *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 11:54:20 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 14:54:20 -0400 Subject: [Ns-bugs] [Bug 343] utils/bench-packets is broken and asserts In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=343 ------- Comment #1 from raj.b at gatech.edu 2008-09-12 14:54 ------- How to reproduce: ./waf --shell gdb ./build/debug/utils/bench-packets (gdb) set args --n=100 (gdb) r Starting program: /home/raj/code.nsnam.org/ns-3-dev/build/debug/utils/bench-packets --n=100 [Thread debugging using libthread_db enabled] Running bench-packets with n=100 a=100000 packets/s b=inf packets/s c=100000 packets/s d=100000 packets/s Error: attempting to enable the packet metadata subsystem too late in the simulation, which is not allowed. A common cause for this problem is to enable ASCII tracing after sending any packets. One way to fix this problem is to call ns3::PacketMetadata::Enable () near the beginning of the program, before any packets are sent. [New Thread 0xb6c5eb00 (LWP 9075)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6c5eb00 (LWP 9075)] 0xb7b97a3d in ns3::PacketMetadata::Enable () at ../src/common/packet-metadata.cc:53 53 NS_ASSERT_MSG (!m_metadataSkipped, (gdb) bt #0 0xb7b97a3d in ns3::PacketMetadata::Enable () at ../src/common/packet-metadata.cc:53 #1 0xb7bc092d in ns3::Packet::EnablePrinting () at ../src/common/packet.cc:469 #2 0x0804b604 in main (argc=0, argv=0xbf9315cc) at ../utils/bench-packets.cc:285 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 14:55:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 17:55:53 -0400 Subject: [Ns-bugs] [Bug 344] New: We need a python regression test Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=344 Summary: We need a python regression test Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu We should have at least one regression test that uses the python bindings to generate traces which are compared a la the C++ script tests. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 14:56:51 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 12 Sep 2008 17:56:51 -0400 Subject: [Ns-bugs] [Bug 345] New: We need nsc regression tests Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=345 Summary: We need nsc regression tests Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu We should have at least one (hopefully more) regression test that uses the nsc example(s) to generate traces which are compared a la the C++ script tests. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 21:27:14 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 13 Sep 2008 00:27:14 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 ------- Comment #4 from tomh at tomh.org 2008-09-13 00:27 ------- It is not clear that this is still a bug. The test procedure to reproduce on the current release candidate is ./waf configure ./waf --regression (remove mercurial) ./waf --regression (crashes) whereas Mathieu suggests that this is operator error to change the platform (remove mercurial) and not rerun configure. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 12 22:04:02 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 13 Sep 2008 01:04:02 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Comment #5 from craigdo at ee.washington.edu 2008-09-13 01:04 ------- Well, I don't know about operator error. The way the test for hg has been done has changed. The sequence Tom posted worked fine until last week, but the test for hg is no longer dynamic, it is now based on configure results; so the way the regression tests work has quietly changed. That said, I'm fine with having to type configure in order to change how the regression tests behave. It just means changing (slightly) the way I've been doing some of the final tarball tests. This is a case where I knew too much about how the internals of the wscript were working and I knew I could do this without doing the configure. I'll go ahead and (re) close this bug and assume that our policy from now on is that any change to the underlying system like this requires a ./waf configure (and that any future test should be based on configure results). -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 13 11:10:50 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 13 Sep 2008 14:10:50 -0400 Subject: [Ns-bugs] [Bug 346] New: ns-3 fails to build if librt is not found Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=346 Summary: ns-3 fails to build if librt is not found Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: sam.jansen at gmail.com librt is not marked as mandatory in the ns-3 build, but if it doesn't exist, ns-3 programs will not link. Problem one is that they still require clock_getres, which is in librt. Problem two is that they still require pthread functions. If ns-3 programs are not linked with librt, nothing pulls in pthread. On my system I can compile with -pthread, but I do not have librt installed. Nor is it easy to install, because I am building ns-3 with a 32-bit cross-compiler. The actual errors are just undefined dependency errors: $ ./waf Entering directory `/usr/local/home/nsc/ns-3-dev/build' [469/507] cxx_link: build/debug/samples/main-callback_2.o -> build/debug/samples/main-callback i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_join' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_create' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_mutexattr_init' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_mutexattr_settype' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_condattr_setpshared' collect2: ld returned 1 exit status It only got this far after I fixed the dependency on clock_getres by patching src/simulator/wall-clock-simulator to only call this function if HAVE_RT is defined. This makes it rather hard for me to do 32-bit versus 64-bit testing of NSC which is required for the regression testing of the NSC component of ns-3. I pulled ns-3 from mercurial this morning (9am PDT, September 13 2008). The gcc version is 4.2.2. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Sep 13 11:38:34 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sat, 13 Sep 2008 14:38:34 -0400 Subject: [Ns-bugs] [Bug 346] ns-3 fails to build if librt is not found In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=346 ------- Comment #1 from sam.jansen at gmail.com 2008-09-13 14:38 ------- A little bit of extra information: I do actually have librt installed, it's just in a non-standard place (/lib32 for 32-bit compat libs). Perhaps the resolution to this bug is that librt should be mandatory? I'm not sure. My next problem is that I don't know how to make waf add /lib32 to the search path from the command line. The documentation, of course, isn't helping. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 10:52:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 13:52:32 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 ------- Comment #6 from tomh at tomh.org 2008-09-14 13:52 ------- (In reply to comment #5) > Well, I don't know about operator error. The way the test for hg has been done > has changed. The sequence Tom posted worked fine until last week, but the test > for hg is no longer dynamic, it is now based on configure results; so the way > the regression tests work has quietly changed. > > That said, I'm fine with having to type configure in order to change how the > regression tests behave. It just means changing (slightly) the way I've been > doing some of the final tarball tests. This is a case where I knew too much > about how the internals of the wscript were working and I knew I could do this > without doing the configure. > > I'll go ahead and (re) close this bug and assume that our policy from now on is > that any change to the underlying system like this requires a ./waf configure > (and that any future test should be based on configure results). > I think it is reasonable to reconfigure when the system changes. I would not have reopened the bug for that reason. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 11:18:45 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 14:18:45 -0400 Subject: [Ns-bugs] [Bug 348] New: regression tests do not work in private or disconnected networks Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 Summary: regression tests do not work in private or disconnected networks Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: regression AssignedTo: ns-bugs at isi.edu ReportedBy: tomh at tomh.org A typical use case is that someone will download the release and use it on a machine where it is not well connected to the Internet, or where the user's http_proxy variable is not set. A user may first download the release tarball only. Suppose this tarball is downloaded onto a machine where either it is behind a NAT and http_proxy is not set, or the machine may not even have reachability to the public network. For instance, a user who wants to try out ns-3 during a train ride. I think the behavior in this case, regardless of whether hg is installed or not, is reasonable with the current release candidate; a user who types in "./waf --regression" on this released version will get a connect error in a reasonably short time: "Abort: name or service name not known". How to remedy this can be documented; waf could even output some suggestions if this socket error occurs. However, what if this user then tries to separately download the matching regression trace tarball and unpack it on the machine? He or she will put these regression traces in the ns-3.2/regression trace directory, and try again "./waf --regression" and will get this type of error: ========== Running Regression Tests ========== Retrieving ns-3.2-RC2-bis-ref-traces.tar.bz2 from web. Traceback (most recent call last): File "./waf", line 141, in Scripting.prepare() File "/home/tomh/ns-3.2-RC2-bis/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 207, in prepare main() File "/home/tomh/ns-3.2-RC2-bis/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 299, in main if fun:fun() File "/home/tomh/ns-3.2-RC2-bis/wscript", line 451, in shutdown run_regression() File "/home/tomh/ns-3.2-RC2-bis/wscript", line 934, in run_regression urllib.urlretrieve(REGRESSION_TRACES_URL + traceball, traceball) File "/usr/lib/python2.5/urllib.py", line 89, in urlretrieve return _urlopener.retrieve(url, filename, reporthook, data) File "/usr/lib/python2.5/urllib.py", line 222, in retrieve fp = self.open(url, data) File "/usr/lib/python2.5/urllib.py", line 190, in open return getattr(self, name)(url) File "/usr/lib/python2.5/urllib.py", line 325, in open_http h.endheaders() File "/usr/lib/python2.5/httplib.py", line 860, in endheaders self._send_output() File "/usr/lib/python2.5/httplib.py", line 732, in _send_output self.send(msg) File "/usr/lib/python2.5/httplib.py", line 699, in send self.connect() File "/usr/lib/python2.5/httplib.py", line 667, in connect socket.SOCK_STREAM): IOError: [Errno socket error] (-2, 'Name or service not known') I verified this on a machine behind a NAT, both with and without hg in the path, and got similar behavior. I wasn't able to drop in the release trace tarball and have it work seamlessly, nor do I know how to make it work. I think that the current behavior is that if these traces are placed into the regression/ directory, waf assumes that it must go out and synchronize these traces, and will fail with the above type of error. So, I think that for user-friendliness, one of these steps needs to be taken: 1) include regression traces in the main tarball, and have the system work self-contained even in the absence of network connectivity 2) document how one can separately download both the release and regression traces, put them together, and make it work in a non-connected environment This also is problematic on the development tree. Similarly, I just tried the following on ns-3-dev: hg pull hg update ./waf --regression (disable network access) ./waf --regression ========== Running Regression Tests ========== Synchronizing reference traces using Mercurial. Pulling http://code.nsnam.org/ns-3-dev-ref-traces from repo. abort: error: No address associated with nodename Synchronizing reference traces using Mercurial failed. I really ought to be able to tell the system "Just use whatever regression traces you have downloaded in the past-- do not try to synchronize them" Can I do that somehow? ./waf configure --offline or ./waf configure --disable-updates? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 11:40:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 14:40:32 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-14 14:40 ------- changeset fc078b692b68 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 13:37:50 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 16:37:50 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #2 from tomh at tomh.org 2008-09-14 16:37 ------- Does not work for me (OS X, ppc); I still cannot run regression when disconnected from the network. I still get: powerbook:/scratch/hg/ns-3-dev% ./waf --regression Entering directory `/scratch/hg/ns-3-dev/build' Compilation finished successfully ========== Running Regression Tests ========== Synchronizing reference traces using Mercurial. Pulling http://code.nsnam.org/ns-3.2-RC2-bis-ref-traces from repo. abort: error: No address associated with nodename Synchronizing reference traces using Mercurial failed. I do not see from the changeset how waf is detecting that I am offline. Also, I don't understand why you changed the VERSION flag on ns-3-dev repo. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 17:57:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 20:57:48 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-14 20:57 ------- (In reply to comment #2) > Does not work for me (OS X, ppc); I still cannot run regression when > disconnected from the network. I still get: > > powerbook:/scratch/hg/ns-3-dev% ./waf --regression > Entering directory `/scratch/hg/ns-3-dev/build' > Compilation finished successfully > ========== Running Regression Tests ========== > Synchronizing reference traces using Mercurial. > Pulling http://code.nsnam.org/ns-3.2-RC2-bis-ref-traces from repo. > abort: error: No address associated with nodename > Synchronizing reference traces using Mercurial failed. > > I do not see from the changeset how waf is detecting that I am offline. It does not but, if you uncompress the regression tarballs, it won't try to fetch them again now which I consider is a fix for your problem good enough for the release. Please mark bug fixed if this is ok. If this is not ok, you will have to fix it yourself: it's just a python script after all. > > Also, I don't understand why you changed the VERSION flag on ns-3-dev repo. ha, I screwed up that part. reverted. sorry about that. > -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 18:01:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 21:01:11 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 ------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-09-14 21:01 ------- I should point out that I disagree that the solution is to add yet another flag to our waf scripts. The real solution is to clealy split all this crap network access from the main waf scripts but you already refused to do this so I can't do much more. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 18:33:41 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 21:33:41 -0400 Subject: [Ns-bugs] [Bug 335] ./waf --regression no longer works without mercurial present In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=335 ------- Comment #7 from craigdo at ee.washington.edu 2008-09-14 21:33 ------- I don't want to belabor this, but I didn't open the bug because "the behavior changed to reconfigure when the system changes." I reopened the bug becuase I had successfully tested the "fetch-the-bits-rom-the-web" behavior many, many times without reconfiguring over the past seven months; and when I tried it for the nth time last week, it failed. I opened the bug because, from my perspective, regression withot Mercurial was *broken*. I used it the way I had used it since April, and it no longer did what it used to. This is usually called a regression, although in this case it turned out to be an (I'm pretty sure) undocumented behavioral change. This bug begs the question of how changes to the build system (or the existing build system) are documented. We have tons of documentation on API, but really nothing on build options. There should have been a place to note this change. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 18:42:12 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Sun, 14 Sep 2008 21:42:12 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 ------- Comment #5 from craigdo at ee.washington.edu 2008-09-14 21:42 ------- We've been pulled in a lot of different directions regarding various options, platforms, regression tests, networks, no networks, etc. I think we need to take some time after ns-3.2 and figure out what ecactly we want this stuff to do and actually design a solution. I saw an email about ns-3.3 priorities fly by. I think that a build system evaluation and cleanup is in order for that release. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Sep 14 21:27:49 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 00:27:49 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 ------- Comment #6 from tomh at tomh.org 2008-09-15 00:27 ------- > > > > I do not see from the changeset how waf is detecting that I am offline. > > It does not but, if you uncompress the regression tarballs, it won't try to > fetch them again now which I consider is a fix for your problem good enough for > the release. Please mark bug fixed if this is ok. If this is not ok, you will > have to fix it yourself: it's just a python script after all. Not working for me still. We can chat about it tomorrow AM. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 03:48:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 06:48:47 -0400 Subject: [Ns-bugs] [Bug 344] We need a python regression test In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=344 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from gjcarneiro at gmail.com 2008-09-15 06:48 ------- Fixed in 3697:97c84e70a7db Caveat: Python scripts cannot generate ascii traces (see bug #155), so only pcap files are compared. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 11:38:59 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 14:38:59 -0400 Subject: [Ns-bugs] [Bug 349] New: packet unit test fails on optimized build Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=349 Summary: packet unit test fails on optimized build Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: general AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu On x86, Ubuntu 8.04, g++ 4.2.3, configured as with "-d optimized --disable-python", configure result was: ---- Summary of optional NS-3 features: Threading Primitives : enabled Real Time Simulator : enabled GtkConfigStore : enabled SQlite stats data output : enabled Network Simulation Cradle : not enabled (--enable-nsc configure option not given) Python Bindings : not enabled (disabled by user request) Ran unit tests with ./waf check, got: ../src/common/packet.cc:836: expected 1000, got 134606971 ../src/common/packet.cc:836: assertion `DoCheck (p, "../src/common/packet.cc", 836, 1, 1,0,1000)' failed. ../src/common/packet.cc:838: expected 1000, got 115 ../src/common/packet.cc:838: assertion `DoCheck (copy, "../src/common/packet.cc", 838, 1, 1,0,1000)' failed. ../src/common/packet.cc:841: expected 1000, got 115 ../src/common/packet.cc:841: expected 1000, got 3073946656 ../src/common/packet.cc:841: assertion `DoCheck (p, "../src/common/packet.cc", 841, 2, 1,0,1000, 2,0,1000)' failed. ../src/common/packet.cc:842: expected 1000, got 115 ../src/common/packet.cc:842: assertion `DoCheck (copy, "../src/common/packet.cc", 842, 1, 1,0,1000)' failed. ../src/common/packet.cc:848: expected 1000, got 115 ../src/common/packet.cc:848: assertion `DoCheck (&c0, "../src/common/packet.cc", 848, 1, 1,0,1000)' failed. ../src/common/packet.cc:849: expected 1000, got 115 ../src/common/packet.cc:849: assertion `DoCheck (&c1, "../src/common/packet.cc", 849, 1, 1,0,1000)' failed. ../src/common/packet.cc:850: expected 1000, got 115 ../src/common/packet.cc:850: assertion `DoCheck (copy, "../src/common/packet.cc", 850, 1, 1,0,1000)' failed. ../src/common/packet.cc:852: expected 1000, got 115 ../src/common/packet.cc:852: expected 1000, got 3073946656 ../src/common/packet.cc:852: assertion `DoCheck (&c0, "../src/common/packet.cc", 852, 2, 1,0,1000, 10,0,1000)' failed. ../src/common/packet.cc:853: expected 1000, got 115 ../src/common/packet.cc:853: assertion `DoCheck (&c1, "../src/common/packet.cc", 853, 1, 1,0,1000)' failed. ../src/common/packet.cc:854: expected 1000, got 115 ../src/common/packet.cc:854: assertion `DoCheck (copy, "../src/common/packet.cc", 854, 1, 1,0,1000)' failed. ../src/common/packet.cc:861: expected 10, got 3073946656 ../src/common/packet.cc:861: assertion `DoCheck (frag0, "../src/common/packet.cc", 861, 3, 1,0,10, 2,0,10, 3,0,10)' failed. ../src/common/packet.cc:863: expected 90, got 3073946656 ../src/common/packet.cc:863: assertion `DoCheck (frag1, "../src/common/packet.cc", 863, 3, 1,0,90, 2,0,90, 4,0,90)' failed. ../src/common/packet.cc:865: expected 900, got 3073946656 ../src/common/packet.cc:865: assertion `DoCheck (frag2, "../src/common/packet.cc", 865, 3, 1,0,900, 2,0,900, 5,0,900)' failed. ../src/common/packet.cc:811: expected 6, got 0 ../src/common/packet.cc:868: assertion `DoCheck (frag1, "../src/common/packet.cc", 868, 6, 1,0,90, 2,0,90, 4,0,90, 1,90,990, 2,90,990, 5,90,990)' failed. ../src/common/packet.cc:870: expected 10, got 3073946656 ../src/common/packet.cc:870: assertion `DoCheck (frag0, "../src/common/packet.cc", 870, 3, 1,0,10, 2,0,10, 3,0,10)' failed. ../src/common/packet.cc:811: expected 9, got 0 ../src/common/packet.cc:875: assertion `DoCheck (frag0, "../src/common/packet.cc", 875, 9, 1,0,10, 2,0,10, 3,0,10, 1,10,100, 2,10,100, 4,10,100, 1,100,1000, 2,100,1000, 5,100,1000)' failed. ../src/common/packet.cc:885: expected 1000, got 4294966519 ../src/common/packet.cc:885: assertion `DoCheck (p, "../src/common/packet.cc", 885, 1, 20,0,1000)' failed. ../src/common/packet.cc:887: expected 1000, got 4294966519 ../src/common/packet.cc:887: assertion `DoCheck (p, "../src/common/packet.cc", 887, 1, 20,0,1000)' failed. ../src/common/packet.cc:896: expected 100, got 122 ../src/common/packet.cc:896: assertion `DoCheck (tmp, "../src/common/packet.cc", 896, 1, 20,0,100)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:898: assertion `DoCheck (tmp, "../src/common/packet.cc", 898, 1, 20,10,110)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:901: assertion `DoCheck (tmp, "../src/common/packet.cc", 901, 1, 20,0,100)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:903: assertion `DoCheck (tmp, "../src/common/packet.cc", 903, 1, 20,10,110)' failed. ../src/common/packet.cc:907: expected 100, got 122 ../src/common/packet.cc:907: assertion `DoCheck (tmp, "../src/common/packet.cc", 907, 1, 20,0,100)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:909: assertion `DoCheck (tmp, "../src/common/packet.cc", 909, 1, 20,0,100)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:912: assertion `DoCheck (tmp, "../src/common/packet.cc", 912, 1, 20,0,100)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:914: assertion `DoCheck (tmp, "../src/common/packet.cc", 914, 1, 20,0,100)' failed. ../src/common/packet.cc:922: expected 156, got 123 ../src/common/packet.cc:922: assertion `DoCheck (tmp, "../src/common/packet.cc", 922, 1, 20,0,156)' failed. ../src/common/packet.cc:924: expected 36, got 3 ../src/common/packet.cc:924: assertion `DoCheck (tmp, "../src/common/packet.cc", 924, 1, 20,0,36)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:927: assertion `DoCheck (a, "../src/common/packet.cc", 927, 1, 20,0,36)' failed. ../src/common/packet.cc:938: expected 1000, got 122 ../src/common/packet.cc:938: assertion `DoCheck (tmp, "../src/common/packet.cc", 938, 1, 20,0,1000)' failed. ../src/common/packet.cc:943: expected 10, got 117 ../src/common/packet.cc:943: assertion `DoCheck (a, "../src/common/packet.cc", 943, 1, 10,0,10)' failed. ../src/common/packet.cc:811: expected 1, got 0 ../src/common/packet.cc:945: assertion `DoCheck (tmp, "../src/common/packet.cc", 945, 1, 10,0,10)' failed. FAIL Packet -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 11:51:15 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 14:51:15 -0400 Subject: [Ns-bugs] [Bug 349] packet unit test fails on optimized build In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=349 ------- Comment #1 from raj.b at gatech.edu 2008-09-15 14:51 ------- This is out of changeset: 3699:29473501ade8 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 13:00:38 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 16:00:38 -0400 Subject: [Ns-bugs] [Bug 349] packet unit test fails on optimized build In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=349 ------- Comment #2 from raj.b at gatech.edu 2008-09-15 16:00 ------- Created an attachment (id=254) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=254&action=view) valgrind output -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 14:18:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 17:18:53 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 evensky at dancer.ca.sandia.gov changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #253 is|0 |1 obsolete| | ------- Comment #2 from evensky at dancer.ca.sandia.gov 2008-09-15 17:18 ------- Created an attachment (id=255) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=255&action=view) updated version, now prints out the size of the tx Queue before the Send. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 15:52:16 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 18:52:16 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #3 from evensky at dancer.ca.sandia.gov 2008-09-15 18:52 ------- To clarify, what I expect to happen is that PacketSocket::Send will not return -1, and to the best of my knowledge, the number of items in the DropTail queue, contained in av, returned via side effect in node::GetDevice(0)GetAttribute("TxQueue",av) will not increase. NOTE: that the current version has the code that uses SetSendCallback #ifdef'ed out, so this is just using PacketQueue::Send. What I am seeing is each call to SrcRtSwitch::SendPacket seems to add another item to the Queue, but nothing ever seems to take things off of it, so that after 100 Sends, the DropTail queue fills up and the Send in the above SendPacket method fails. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 16:17:57 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Mon, 15 Sep 2008 19:17:57 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #4 from evensky at dancer.ca.sandia.gov 2008-09-15 19:17 ------- Created an attachment (id=256) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=256&action=view) example of a failed run. To generate the error attached I did a: ./p2p_test --size=5050001 > failed.output The uploaded file, failed.output, has the following text inserted in it to show where the error occurs. What I expected for correct operation was that this last byte would be written out and the 'Send returned -1' that is printed after the NOTE, would have written 'Send returned 0' as it had for previous Sends. NOTE: The line below is the first failed packet. Before we try to do a send around line 310 in SrcRtSwitch::SendPacket(), the queue has filled up. I don't think it should do that. When we do try the Send in SendPacket, it returns -1 indicating a failure. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 21:00:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 16 Sep 2008 00:00:47 -0400 Subject: [Ns-bugs] [Bug 345] We need nsc regression tests In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=345 ------- Comment #1 from sam.jansen at gmail.com 2008-09-16 00:00 ------- See also bug 347, which details the difficulty of 32 vs 64 bit simulations/traces with NSC. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Sep 15 22:17:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 16 Sep 2008 01:17:04 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-16 01:17 ------- the following untested patch should fix your problem: diff -r a60aeddab0fe src/node/packet-socket.cc --- a/src/node/packet-socket.cc Sun Sep 14 17:55:30 2008 -0700 +++ b/src/node/packet-socket.cc Mon Sep 15 22:16:54 2008 -0700 @@ -26,6 +26,7 @@ #include "ns3/packet.h" #include "ns3/uinteger.h" #include "ns3/trace-source-accessor.h" +#include "ns3/simulator.h" #include @@ -328,7 +329,8 @@ PacketSocket::SendTo (Ptr p, uin } if (!error) { - NotifyDataSent (p->GetSize ()); + Simulator::ScheduleNow (&PacketSocket::NotifyDataSent, this, p->GetSize ()); + //NotifyDataSent (p->GetSize ()); } if (error) -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 16 07:46:32 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 16 Sep 2008 10:46:32 -0400 Subject: [Ns-bugs] [Bug 350] New: Ptr has operator < but no operator >, causes subtle bugs Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=350 Summary: Ptr has operator < but no operator >, causes subtle bugs Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com I had a comparison operator involving smart pointer fields that looked like this: bool PyViz::TransmissionSampleKey::operator < (PyViz::TransmissionSampleKey const &other) const { if (this->transmitter < other.transmitter) { return true; } if (this->transmitter > other.transmitter) { return false; } if (this->receiver < other.receiver) { return true; } if (this->receiver > other.receiver) { return false; } if (this->channel < other.channel) { return true; } else { return false; } } I was using these PyViz::TransmissionSampleKey values as keys of a std::map, and the std::map was going berserk, with completely erroneous operation. After many hours of debugging I tracked it down to the above comparison function. It turns out that we have a custom Ptr operator < function, but no operator >. It seems that C++ is autogenerating some operator > function, but the autogenerated function and the manual function are not self-consistent. To fix my problem I am changing the > comparisons to !=, but I think this might bite someone else in the future. In principle, defining the remaining operators should be enough to solve the problems. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 16 10:14:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 16 Sep 2008 13:14:28 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #6 from evensky at dancer.ca.sandia.gov 2008-09-16 13:14 ------- Tried Mathieu's untested patch, but it didn't work for me. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 16 10:23:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 16 Sep 2008 13:23:28 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #7 from mathieu.lacage at sophia.inria.fr 2008-09-16 13:23 ------- yes, it occured to me that it would not work. This is a pretty deep/tricky bug. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 16 21:57:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 00:57:03 -0400 Subject: [Ns-bugs] [Bug 348] regression tests do not work in private or disconnected networks In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 ------- Comment #7 from tomh at tomh.org 2008-09-17 00:57 ------- > > Not working for me still. We can chat about it tomorrow AM. > Deferred until post-3.2 release. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 07:50:19 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 10:50:19 -0400 Subject: [Ns-bugs] [Bug 351] New: Python: ns3.Schedule + import threading == crash Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=351 Summary: Python: ns3.Schedule + import threading == crash Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: python bindings AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com In some manually written code I forgot to acquire/release the Python GIL. The patch is small but important. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 07:50:50 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 10:50:50 -0400 Subject: [Ns-bugs] [Bug 351] Python: ns3.Schedule + import threading == crash In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=351 ------- Comment #1 from gjcarneiro at gmail.com 2008-09-17 10:50 ------- Created an attachment (id=257) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=257&action=view) patch -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 09:34:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 12:34:55 -0400 Subject: [Ns-bugs] [Bug 351] Python: ns3.Schedule + import threading == crash In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=351 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-17 12:34 ------- This patch looks good to me for ns-3-dev as of now. You would need to get approval from tom or craig before commiting though. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 10:33:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 13:33:30 -0400 Subject: [Ns-bugs] [Bug 352] New: Wifi STA mac address problems Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=352 Summary: Wifi STA mac address problems Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com In Wifi infrastructure more: 1. STA X sends a broadcast 2. AP Y retransmits the broadcast for all nodes to receive 3. STA X receives the retransmission and receives it Step 3 is bad, the STA should not forward to the upper layers broadcasts that it has sent. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 10:34:20 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 13:34:20 -0400 Subject: [Ns-bugs] [Bug 352] Wifi STA mac address problems In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=352 ------- Comment #1 from gjcarneiro at gmail.com 2008-09-17 13:34 ------- Created an attachment (id=258) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=258&action=view) patch to fix it -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 12:34:52 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 15:34:52 -0400 Subject: [Ns-bugs] [Bug 311] Tcp socket close returns -1 but does not set errno. In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=311 ------- Comment #2 from raj.b at gatech.edu 2008-09-17 15:34 ------- It seems the purpose of this check was to prevent a double close, BUT it apparently is superfluous in any case, because the state machine has the following entry in it: aT[CLOSED][APP_CLOSE] = SA (CLOSED, NO_ACT); Since we call ProcessEvent(APP_CLOSE) in this code, in the case of already being in the CLOSED state, nothing would happen in terms of state change or action in response to closing the socket. As such, deleting the check would cause a double close to silently succeed, and return 0. Really, this is what should have been done, because the processing of the m_state variable shouldn't explicitly be done in this code since it is handled by the ProcessEvent/Action methods. diff -r 6105fe16df43 src/internet-stack/tcp-socket-impl.cc --- a/src/internet-stack/tcp-socket-impl.cc Tue Sep 16 11:55:52 2008 -0700 +++ b/src/internet-stack/tcp-socket-impl.cc Wed Sep 17 15:33:07 2008 -0400 @@ -296,10 +296,6 @@ TcpSocketImpl::Close (void) { NS_LOG_FUNCTION_NOARGS (); - if (m_state == CLOSED) - { - return -1; - } if (m_pendingData && m_pendingData->Size() != 0) { // App close with pending data must wait until all data transmitted m_closeOnEmpty = true; -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 14:44:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 17:44:53 -0400 Subject: [Ns-bugs] [Bug 345] We need nsc regression tests In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=345 sam.jansen at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ns-bugs at isi.edu |sam.jansen at gmail.com Status|NEW |ASSIGNED ------- Comment #2 from sam.jansen at gmail.com 2008-09-17 17:44 ------- Created an attachment (id=259) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=259&action=view) Regression test for nsc using tcp-nsc-lfn I've made an NSC regression test that will work with different regression traces in 32 and 64 bit mode, and does not run when NSC is disabled. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 15:20:14 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 17 Sep 2008 18:20:14 -0400 Subject: [Ns-bugs] [Bug 351] Python: ns3.Schedule + import threading == crash In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=351 ------- Comment #3 from gjcarneiro at gmail.com 2008-09-17 18:20 ------- Craig? Let your verdict be known. Leave it as P1 and commit, or move it to P3? My opinion as maintainer of the Python bindings is to commit. It's a trivial fix and has zero chance of breaking compilation even on weird platforms (the function PyEval_ThreadsInitialized() is Python 2.4+ only, but there is a compatibility macro for older Pythons). -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 17 21:00:53 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 00:00:53 -0400 Subject: [Ns-bugs] [Bug 351] Python: ns3.Schedule + import threading == crash In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=351 craigdo at ee.washington.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 18 03:15:12 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 06:15:12 -0400 Subject: [Ns-bugs] [Bug 354] New: Promiscuous mode tracing inconsistencies Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=354 Summary: Promiscuous mode tracing inconsistencies Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com I am playing with my gjc/ns-3-pyviz branch and been noticing inconsistencies wrt. tracing and promiscuous mode. I am sorry I did not catch this sooner, but better late than never. - CsmaNetDevice does not generate any trace when a packet is received promiscuously (PACKET_OTHERHOST). In my branch, I experimentally added a new PromiscRx trace and generate it for all packets but only when there is a promiscuous mode protocol handler: if (!m_promiscRxCallback.IsNull ()) { m_promiscRxTrace (originalPacket, packetType); m_promiscRxCallback (this, packet, protocol, header.GetSource (), header.GetDestination (), packetType); } - Wifi does not have a separate protocol handler for promiscuous mode, instead unconditionally always generates Rx trace for all packets, even PACKET_OTHERHOST; - PointToPointNetDevice does not even care about destination addresses, it's like it is permanently in promiscuous mode. I think it would be better to converge. On one hand, I can probably manage to not use a PromiscRx trace, by looking at the netdevice and checking if it is part of at BridgeNetDevice (once a proper BridgeNetDevice API is provided for that). On the other hand, doing so would be more complex in terms of code and probably less efficient computationally than listening to a PromiscRx trace. Opinions? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 18 04:01:18 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 07:01:18 -0400 Subject: [Ns-bugs] [Bug 355] New: Python scripts may crash on shutdown Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=355 Summary: Python scripts may crash on shutdown Product: ns-3 Version: ns-3.2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: python bindings AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com #0 0x00007f233619e095 in raise () from /lib/libc.so.6 #1 0x00007f233619faf0 in abort () from /lib/libc.so.6 #2 0x00007f23361972df in __assert_fail () from /lib/libc.so.6 #3 0x00007f2337392cb8 in PyGILState_Ensure () at Python/pystate.c:497 #4 0x00007f2335bec8ce in PyNs3Application__PythonHelper::DoDispose (this=0xed7360) at debug/bindings/python/ns3_module_node.cc:6984 #5 0x00007f23351a23e9 in ns3::Object::Dispose (this=0xed7360) at ../src/core/object.cc:136 #6 0x00007f233529a4a4 in ns3::Node::DoDispose (this=0x702e70) at ../src/node/node.cc:155 #7 0x00007f23351a23e9 in ns3::Object::Dispose (this=0x702e70) at ../src/core/object.cc:136 #8 0x00007f23352b8a62 in ~NodeListPriv (this=0x7aa990) at ../src/node/node-list.cc:110 #9 0x00007f23351a1d9d in ns3::Object::MaybeDelete (this=0x7aa990) at ../src/core/object.cc:246 #10 0x00007f2335b8efa6 in ns3::Object::Unref (this=0x7aa990) at debug/ns3/object.h:346 #11 0x00007f23352baa57 in ~Ptr (this=0x7f23359190e0) at debug/ns3/ptr.h:407 #12 0x00007f23352b891a in __tcf_1 () at ../src/node/node-list.cc:81 #13 0x00007f23361a1110 in exit () from /lib/libc.so.6 #14 0x00007f233618a1cb in __libc_start_main () from /lib/libc.so.6 #15 0x0000000000400699 in _start () This is a harmless problem, but ugly. It happens because NS-3 keeps references to nodes. Calling ns3.Simulator.Destroy() in the Python script fixes this problem, though. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 18 09:12:59 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 12:12:59 -0400 Subject: [Ns-bugs] [Bug 355] Python scripts may crash on shutdown In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=355 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-18 12:12 ------- I don't really understand the problem. A script _must_ call Destroy before shutdown to ensure correct program shutdown. Not doing so can lead to unpredictable results. I will mark as invalid unless you provide more information about the context -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 18 09:15:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 12:15:30 -0400 Subject: [Ns-bugs] [Bug 241] Trace sources not clearly documented, trace sinks not clearly documented In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=241 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-18 12:15 ------- *** Bug 354 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 18 09:15:30 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 12:15:30 -0400 Subject: [Ns-bugs] [Bug 354] Promiscuous mode tracing inconsistencies In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=354 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-18 12:15 ------- Each kind of net device provides its own trace output independentely from the other devices. What is missing is documentation to describe that in the associated helper, not making them all behave the same. Marking as duplicate of bug 241 *** This bug has been marked as a duplicate of bug 241 *** -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 18 16:08:58 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 18 Sep 2008 19:08:58 -0400 Subject: [Ns-bugs] [Bug 356] New: tcp-nsc-lfn fails with --valgrind selected Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=356 Summary: tcp-nsc-lfn fails with --valgrind selected Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: sample programs AssignedTo: ns-bugs at isi.edu ReportedBy: craigdo at ee.washington.edu ./waf --run examples/tcp-nsc-lfn --valgrind produces errors. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 19 10:21:57 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 19 Sep 2008 13:21:57 -0400 Subject: [Ns-bugs] [Bug 357] New: Socket::Listen takes a queueLimit argument but it can't be used Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=357 Summary: Socket::Listen takes a queueLimit argument but it can't be used Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: node module AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 19 10:23:13 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 19 Sep 2008 13:23:13 -0400 Subject: [Ns-bugs] [Bug 357] Socket::Listen takes a queueLimit argument but it can't be used In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=357 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-19 13:23 ------- the reason this argument can't be used is that the socket API uses accept callbacks so, it is the application which is responsible for buffering incoming connection requests, not the Socket implementation. I would like to remove the queueLimit argument of the listen call. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 19 11:18:56 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 19 Sep 2008 14:18:56 -0400 Subject: [Ns-bugs] [Bug 358] New: calling listen on non-closed TCP sockets sends resets, should fail and do nothing Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=358 Summary: calling listen on non-closed TCP sockets sends resets, should fail and do nothing Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: devices AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu Linux's inet_listen returns EINVAL when you call listen on a socket in any state other than SS_UNCONNECTED. The GTNetS port always succeeds on calling listen, and usually sends a reset, or does nothing in response in just a few cases. It should fail with ns-3's ERROR_INVAL and NOT send resets. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 19 11:19:10 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 19 Sep 2008 14:19:10 -0400 Subject: [Ns-bugs] [Bug 358] calling listen on non-closed TCP sockets sends resets, should fail and do nothing In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=358 raj.b at gatech.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Component|devices |internet-stack -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 19 11:41:01 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 19 Sep 2008 14:41:01 -0400 Subject: [Ns-bugs] [Bug 359] New: *SocketImpl::Bind returns something other than -1 Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=359 Summary: *SocketImpl::Bind returns something other than -1 Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: raj.b at gatech.edu Both UdpSocketImpl and (due to copy paste) TcpSocketImpl return ERROR_INVAL in the Bind calls. They should return -1 and set m_errno = ERROR_INVAL -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Sep 19 11:46:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Fri, 19 Sep 2008 14:46:03 -0400 Subject: [Ns-bugs] [Bug 359] *SocketImpl::Bind returns something other than -1 In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=359 ------- Comment #1 from raj.b at gatech.edu 2008-09-19 14:46 ------- Created an attachment (id=260) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=260&action=view) Fix -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 03:16:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 06:16:11 -0400 Subject: [Ns-bugs] [Bug 361] New: Make NqstaWifiMac::GetBssid () public Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=361 Summary: Make NqstaWifiMac::GetBssid () public Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: wifi AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com For my visualizer I needed to make NqstaWifiMac::GetBssid () public, as I found no other way: http://code.nsnam.org/gjc/ns-3-pyviz/rev/ebb1d7296a6e -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 10:02:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 13:02:47 -0400 Subject: [Ns-bugs] [Bug 362] New: "Test for possibly unreachable code-- please file a bug report if this is ever hit" Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=362 Summary: "Test for possibly unreachable code-- please file a bug report if this is ever hit" Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com Guess what? :-) #0 0x00007f54dbb08f62 in ns3::ArpL3Protocol::Lookup (this=0xe4c610, packet=@0x421e6ed0, destination={m_address = 167837953}, device=@0x421e6ee0, cache=@0x421e6ec0, hardwareDestination=0x421e6fd0) at ../src/internet-stack/arp-l3-protocol.cc:224 224 NS_FATAL_ERROR ("Test for possibly unreachable code-- please file a bug report if this is ever hit"); In my case, I have a wifi node sending a flow to an AP; after a while I drag the node out of wifi range, and then after a short time that error occurs. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 10:16:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 13:16:47 -0400 Subject: [Ns-bugs] [Bug 356] tcp-nsc-lfn fails with --valgrind selected In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=356 ------- Comment #1 from sam.jansen at gmail.com 2008-09-23 13:16 ------- Pasting discussion from IRC: 05:00 < sam_> NSC works fine in valgrind, if valgrind works.... 05:00 < sam_> valgrind doesn't support all the instructions NSC uses in 64-bit last I checked (with svn version of valgrind) 05:00 < sam_> (due to the linux kernel using quite a few asm statements) 05:01 < sam_> I believe it should work in 32-bit mode fine, though 05:02 < sam_> fw_ has used it in 32-bit successfully at least Due to the lack of information here it isn't clear whether this is a 32-bit or 64-bit problem. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 13:30:22 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 16:30:22 -0400 Subject: [Ns-bugs] [Bug 363] New: Socket::SetDataSentCallback has bool return value Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=363 Summary: Socket::SetDataSentCallback has bool return value Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: node module AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr that return value is useless. should be removed. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 13:31:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 16:31:11 -0400 Subject: [Ns-bugs] [Bug 364] New: how do I know if Socket::SetSendCallback works ? Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=364 Summary: how do I know if Socket::SetSendCallback works ? Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: node module AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr that callback will be inoperative on udp sockets. How do I know this ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 13:51:21 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 16:51:21 -0400 Subject: [Ns-bugs] [Bug 365] New: TcpSocketImpl::Recv returns 0 without setting m_errno Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 Summary: TcpSocketImpl::Recv returns 0 without setting m_errno Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr CC: raj.b at gatech.edu it should return 0 _and_ set errno to ERROR_AGAIN -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 13:53:24 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 16:53:24 -0400 Subject: [Ns-bugs] [Bug 365] TcpSocketImpl::Recv returns 0 without setting m_errno In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 ------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-09-23 16:53 ------- same for NscTcpSocketImpl::Recv -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 14:01:55 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 17:01:55 -0400 Subject: [Ns-bugs] [Bug 365] TcpSocketImpl::Recv returns 0 without setting m_errno In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-23 17:01 ------- as florian pointed out, that whole API is problematic for EOF. 0 is a valid return value which does not indicate error so, we can't use it to indicate error. options: - add ERROR_EOF - return -1 - change the Ptr return value to int all are pretty ugly :/ -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 14:16:33 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 17:16:33 -0400 Subject: [Ns-bugs] [Bug 365] TcpSocketImpl::Recv returns 0 without setting m_errno In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-23 17:16 ------- another option to represent EOF would be to return a zero-sized packet. That is not less ugly than the other options. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 14:23:52 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 17:23:52 -0400 Subject: [Ns-bugs] [Bug 356] tcp-nsc-lfn fails with --valgrind selected In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=356 ------- Comment #2 from craigdo at ee.washington.edu 2008-09-23 17:23 ------- Linux version 2.6.24-19-server (buildd at king) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Wed Aug 20 18:43:06 UTC 2008 Target: x86_64-linux-gnu do ./waf --run tcp-nsc-lfn --valgrind get Entering directory `/home/craigdo/repos/ns-3-dev/build' [539/539] ==30003== Memcheck, a memory error detector. ==30003== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==30003== Using LibVEX rev 1804, a library for dynamic binary translation. ==30003== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==30003== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==30003== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==30003== For more details, rerun with: -v ==30003== ==30003== Invalid read of size 8 ==30003== at 0x4015D6E: (within /lib/ld-2.7.so) ==30003== by 0x4011F31: (within /lib/ld-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x401191A: (within /lib/ld-2.7.so) ==30003== by 0x5AFEF8A: (within /lib/libdl-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x5AFF4EC: (within /lib/libdl-2.7.so) ==30003== by 0x5AFEEF0: dlopen (in /lib/libdl-2.7.so) ==30003== by 0x536077B: ns3::NscTcpL4Protocol::SetNscLibrary(std::string const&) (nsc-tcp-l4-protocol.cc:102) ==30003== by 0x52CF198: ns3::AddNscStack(ns3::Ptr, std::string const&) (internet-stack.cc:98) ==30003== by 0x52D32EB: ns3::AddNscInternetStack(ns3::Ptr, std::string const&) (internet-stack.cc:114) ==30003== by 0x54B5957: ns3::InternetStackHelper::Install(ns3::NodeContainer) (internet-stack-helper.cc:74) ==30003== Address 0xb7db258 is 40 bytes inside a block of size 42 alloc'd ==30003== at 0x4C23809: operator new(unsigned long) (vg_replace_malloc.c:230) ==30003== by 0x7A112E0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A120F4: (within /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A12271: std::string::string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x407712: main (tcp-nsc-lfn.cc:62) ==30003== ==30003== Invalid read of size 8 ==30003== at 0x4015D6E: (within /lib/ld-2.7.so) ==30003== by 0x40085B1: (within /lib/ld-2.7.so) ==30003== by 0x4012048: (within /lib/ld-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x401191A: (within /lib/ld-2.7.so) ==30003== by 0x5AFEF8A: (within /lib/libdl-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x5AFF4EC: (within /lib/libdl-2.7.so) ==30003== by 0x5AFEEF0: dlopen (in /lib/libdl-2.7.so) ==30003== by 0x536077B: ns3::NscTcpL4Protocol::SetNscLibrary(std::string const&) (nsc-tcp-l4-protocol.cc:102) ==30003== by 0x52CF198: ns3::AddNscStack(ns3::Ptr, std::string const&) (internet-stack.cc:98) ==30003== by 0x52D32EB: ns3::AddNscInternetStack(ns3::Ptr, std::string const&) (internet-stack.cc:114) ==30003== Address 0xb7db258 is 40 bytes inside a block of size 42 alloc'd ==30003== at 0x4C23809: operator new(unsigned long) (vg_replace_malloc.c:230) ==30003== by 0x7A112E0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A120F4: (within /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A12271: std::string::string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x407712: main (tcp-nsc-lfn.cc:62) ==30003== ==30003== Invalid read of size 8 ==30003== at 0x4015EE4: (within /lib/ld-2.7.so) ==30003== by 0x40087D1: (within /lib/ld-2.7.so) ==30003== by 0x4012048: (within /lib/ld-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x401191A: (within /lib/ld-2.7.so) ==30003== by 0x5AFEF8A: (within /lib/libdl-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x5AFF4EC: (within /lib/libdl-2.7.so) ==30003== by 0x5AFEEF0: dlopen (in /lib/libdl-2.7.so) ==30003== by 0x536077B: ns3::NscTcpL4Protocol::SetNscLibrary(std::string const&) (nsc-tcp-l4-protocol.cc:102) ==30003== by 0x52CF198: ns3::AddNscStack(ns3::Ptr, std::string const&) (internet-stack.cc:98) ==30003== by 0x52D32EB: ns3::AddNscInternetStack(ns3::Ptr, std::string const&) (internet-stack.cc:114) ==30003== Address 0xb7db258 is 40 bytes inside a block of size 42 alloc'd ==30003== at 0x4C23809: operator new(unsigned long) (vg_replace_malloc.c:230) ==30003== by 0x7A112E0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A120F4: (within /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A12271: std::string::string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x407712: main (tcp-nsc-lfn.cc:62) ==30003== ==30003== Invalid read of size 8 ==30003== at 0x4015EE4: (within /lib/ld-2.7.so) ==30003== by 0x400A99D: (within /lib/ld-2.7.so) ==30003== by 0x40061E4: (within /lib/ld-2.7.so) ==30003== by 0x4008677: (within /lib/ld-2.7.so) ==30003== by 0x4012048: (within /lib/ld-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x401191A: (within /lib/ld-2.7.so) ==30003== by 0x5AFEF8A: (within /lib/libdl-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x5AFF4EC: (within /lib/libdl-2.7.so) ==30003== by 0x5AFEEF0: dlopen (in /lib/libdl-2.7.so) ==30003== by 0x536077B: ns3::NscTcpL4Protocol::SetNscLibrary(std::string const&) (nsc-tcp-l4-protocol.cc:102) ==30003== Address 0xb7db258 is 40 bytes inside a block of size 42 alloc'd ==30003== at 0x4C23809: operator new(unsigned long) (vg_replace_malloc.c:230) ==30003== by 0x7A112E0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A120F4: (within /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A12271: std::string::string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x407712: main (tcp-nsc-lfn.cc:62) ==30003== ==30003== Invalid read of size 8 ==30003== at 0x4015EFE: (within /lib/ld-2.7.so) ==30003== by 0x400AB93: (within /lib/ld-2.7.so) ==30003== by 0x40061E4: (within /lib/ld-2.7.so) ==30003== by 0x4008677: (within /lib/ld-2.7.so) ==30003== by 0x4012048: (within /lib/ld-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x401191A: (within /lib/ld-2.7.so) ==30003== by 0x5AFEF8A: (within /lib/libdl-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x5AFF4EC: (within /lib/libdl-2.7.so) ==30003== by 0x5AFEEF0: dlopen (in /lib/libdl-2.7.so) ==30003== by 0x536077B: ns3::NscTcpL4Protocol::SetNscLibrary(std::string const&) (nsc-tcp-l4-protocol.cc:102) ==30003== Address 0xb7dda00 is 56 bytes inside a block of size 59 alloc'd ==30003== at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==30003== by 0x4005F47: (within /lib/ld-2.7.so) ==30003== by 0x400885F: (within /lib/ld-2.7.so) ==30003== by 0x4012048: (within /lib/ld-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x401191A: (within /lib/ld-2.7.so) ==30003== by 0x5AFEF8A: (within /lib/libdl-2.7.so) ==30003== by 0x400DDF5: (within /lib/ld-2.7.so) ==30003== by 0x5AFF4EC: (within /lib/libdl-2.7.so) ==30003== by 0x5AFEEF0: dlopen (in /lib/libdl-2.7.so) ==30003== by 0x536077B: ns3::NscTcpL4Protocol::SetNscLibrary(std::string const&) (nsc-tcp-l4-protocol.cc:102) ==30003== by 0x52CF198: ns3::AddNscStack(ns3::Ptr, std::string const&) (internet-stack.cc:98) ==30003== Warning: set address range perms: large range 141221888 (defined) vex amd64->IR: unhandled instruction bytes: 0x15 0xFF 0xFF 0x0 ==30003== valgrind: Unrecognised instruction at address 0xBC47EDB. ==30003== Your program just tried to execute an instruction that Valgrind ==30003== did not recognise. There are two possible reasons for this. ==30003== 1. Your program has a bug and erroneously jumped to a non-code ==30003== location. If you are running Memcheck and you just saw a ==30003== warning about a bad jump, it's probably your program's fault. ==30003== 2. The instruction is legitimate but Valgrind doesn't handle it, ==30003== i.e. it's Valgrind's fault. If you think this is the case or ==30003== you are not sure, please let us know and we'll try to fix it. ==30003== Either way, Valgrind will now raise a SIGILL signal which will ==30003== probably kill your program. ==30003== ==30003== Process terminating with default action of signal 4 (SIGILL) ==30003== Illegal opcode at address 0xBC47EDB ==30003== at 0xBC47EDB: ??? ==30003== by 0xBC5843F: ??? ==30003== by 0xBC5FAF1: ??? ==30003== by 0xBC4706D: ??? ==30003== by 0xBC0608F: ??? ==30003== by 0xBD19E4E: ??? ==30003== by 0xBD390B7: ??? ==30003== by 0x7FEFFFCEF: ??? ==30003== by 0x7FEFFFD5F: ??? ==30003== by 0x1000009FFFFFFFF: ??? ==30003== by 0xD18C2E27FF: ??? ==30003== by 0x7FEFFFD5F: ??? ==30003== ==30003== ERROR SUMMARY: 6 errors from 5 contexts (suppressed: 10 from 1) ==30003== malloc/free: in use at exit: 2,538,537 bytes in 2,919 blocks. ==30003== malloc/free: 7,915 allocs, 4,996 frees, 2,838,221 bytes allocated. ==30003== For counts of detected errors, rerun with: -v ==30003== searching for pointers to 2,919 not-freed blocks. ==30003== checked 17,852,416 bytes. ==30003== ==30003== ==30003== 3,616 (2,176 direct, 1,440 indirect) bytes in 4 blocks are definitely lost in loss record 325 of 337 ==30003== at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==30003== by 0xBD17A7C: ??? ==30003== by 0xBD17EF8: ??? ==30003== by 0xBD17E10: ??? ==30003== by 0xBD17EC8: ??? ==30003== by 0xBB9A21E: ??? ==30003== by 0xBB9BB65: ??? ==30003== by 0xBB9BD17: ??? ==30003== by 0xBD198F6: ??? ==30003== by 0xBD19C90: ??? ==30003== by 0xBD394B5: ??? ==30003== by 0xBA317D7: ??? ==30003== ==30003== ==30003== 9,827 bytes in 23 blocks are possibly lost in loss record 330 of 337 ==30003== at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==30003== by 0xBD17A7C: ??? ==30003== by 0xBBAF0E5: ??? ==30003== by 0xBD36BF7: ??? ==30003== by 0xBBC9EC2: ??? ==30003== by 0xBBCA05B: ??? ==30003== by 0xBD36CA5: ??? ==30003== by 0xBD366C2: ??? ==30003== by 0xBD19814: ??? ==30003== by 0xBD392A0: ??? ==30003== by 0x52CF1C3: ns3::AddNscStack(ns3::Ptr, std::string const&) (internet-stack.cc:99) ==30003== by 0x52D32EB: ns3::AddNscInternetStack(ns3::Ptr, std::string const&) (internet-stack.cc:114) ==30003== ==30003== ==30003== 44,669 bytes in 970 blocks are possibly lost in loss record 334 of 337 ==30003== at 0x4C23809: operator new(unsigned long) (vg_replace_malloc.c:230) ==30003== by 0x7A112E0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A120F4: (within /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x7A12271: std::string::string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.9) ==30003== by 0x5185F05: std::pair::pair(std::pair const&) (stl_pair.h:90) ==30003== by 0x5185610: ns3::LogComponent::LogComponent(char const*) (log.cc:99) ==30003== by 0x54CB62B: __static_initialization_and_destruction_0(int, int) (sqlite-data-output.cc:34) ==30003== by 0x54CB640: _GLOBAL__I__ZN3ns316SqliteDataOutputC2Ev (sqlite-data-output.cc:239) ==30003== by 0x54CD861: (within /home/craigdo/repos/ns-3-dev/build/debug/libns3.so) ==30003== by 0x513CFFA: (within /home/craigdo/repos/ns-3-dev/build/debug/libns3.so) ==30003== by 0x7FF000A57: ??? ==30003== by 0x400E165: (within /lib/ld-2.7.so) ==30003== ==30003== LEAK SUMMARY: ==30003== definitely lost: 2,176 bytes in 4 blocks. ==30003== indirectly lost: 1,440 bytes in 2 blocks. ==30003== possibly lost: 54,496 bytes in 993 blocks. ==30003== still reachable: 2,480,425 bytes in 1,920 blocks. ==30003== suppressed: 0 bytes in 0 blocks. ==30003== Reachable blocks (those to which a pointer was found) are not shown. ==30003== To see them, rerun with: --leak-check=full --show-reachable=yes Compilation finished successfully Command ['valgrind', '--leak-check=full', '/home/craigdo/repos/ns-3-dev/build/debug/examples/tcp-nsc-lfn'] exited with code -4 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 23 15:03:03 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 23 Sep 2008 18:03:03 -0400 Subject: [Ns-bugs] [Bug 366] New: Packet is not thread-safe Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=366 Summary: Packet is not thread-safe Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr you can't create a packet in a thread and pass it to another thread, even if you forget about it in the first thread. This is because of the global cache used in buffer.cc, packet-metadata.cc, and tag-list.cc -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 02:38:01 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 05:38:01 -0400 Subject: [Ns-bugs] [Bug 366] Packet is not thread-safe In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=366 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #1 from gjcarneiro at gmail.com 2008-09-24 05:38 ------- Good to know this, because I am currently making this mistake :-/ Anyway, in my opinion we do not want to make packets thread safe; doing so would incur a significant performance penalty for non-threaded simulations, so -1 from me. I can easily work around this problem, and I want my optimized simulation scripts to run as fast as they can. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 02:47:39 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 05:47:39 -0400 Subject: [Ns-bugs] [Bug 366] Packet is not thread-safe In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=366 ------- Comment #2 from gjcarneiro at gmail.com 2008-09-24 05:47 ------- It turns out I am not sure I am making that mistake any more. When you say: "you can't create a packet in a thread and pass it to another thread, even if you forget about it in the first thread." Is this really 100% accurate? In my case, I have one thread doing simulation, and the main thread doing GUI stuff. But I use a mutex in the GUI thread, so I am sure that the simulation thread is suspended while I am operating on the packet. Even if there is a global cache, I am pretty sure only one thread is operating on that cache at any given time. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 04:19:43 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 07:19:43 -0400 Subject: [Ns-bugs] [Bug 365] TcpSocketImpl::Recv returns 0 without setting m_errno In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #4 from gjcarneiro at gmail.com 2008-09-24 07:19 ------- How about returning a NULL "pointer" (Ptr ()) on error? Ptr p = socket->Recv (); if (!p) { // check socket->GetErrno (); } -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 04:23:29 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 07:23:29 -0400 Subject: [Ns-bugs] [Bug 364] how do I know if Socket::SetSendCallback works ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=364 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com ------- Comment #1 from gjcarneiro at gmail.com 2008-09-24 07:23 ------- Socket::SetSendCallback should be functional for UDP sockets IMHO. Why would it be hard to implement for UDP sockets? If the implementation knows no better, just call this callback unconditionally after each Send () (preferably via Simulator::Schedule to avoid recursion). -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 04:40:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 07:40:04 -0400 Subject: [Ns-bugs] [Bug 367] New: WiFi STA netdevices flip-flopping Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=367 Summary: WiFi STA netdevices flip-flopping Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: wifi AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com I have been experiencing strange periodic ARP request/reply pairs, approximately once per second, from my Wifi stations. It turns out that the link change callback is being called for wifi netdevices every second, causing ARP caches to be flushed. Some logging I added shows this (the bug appears to come from below the NetDevice layer, from the WifiMac or below layer): 12.155s WifiNetDevice:LinkDown(0xe47f80) 12.155s WifiNetDevice:LinkDown(): link changed 12.1556s WifiNetDevice:LinkUp(0xe47f80) 12.1556s WifiNetDevice:LinkUp(): link changed 12.2009s WifiNetDevice:LinkDown(0xe453e0) 12.2009s WifiNetDevice:LinkDown(): link changed 12.2015s WifiNetDevice:LinkUp(0xe453e0) 12.2015s WifiNetDevice:LinkUp(): link changed 12.2656s WifiNetDevice:LinkDown(0xe42840) 12.2656s WifiNetDevice:LinkDown(): link changed 12.2662s WifiNetDevice:LinkUp(0xe42840) 12.2662s WifiNetDevice:LinkUp(): link changed 12.3641s WifiNetDevice:LinkDown(0xe3fce0) 12.3641s WifiNetDevice:LinkDown(): link changed 12.3647s WifiNetDevice:LinkUp(0xe3fce0) 12.3647s WifiNetDevice:LinkUp(): link changed 13.1484s WifiNetDevice:LinkDown(0xe47f80) 13.1484s WifiNetDevice:LinkDown(): link changed 13.149s WifiNetDevice:LinkUp(0xe47f80) 13.149s WifiNetDevice:LinkUp(): link changed 13.1944s WifiNetDevice:LinkDown(0xe453e0) 13.1944s WifiNetDevice:LinkDown(): link changed 13.1949s WifiNetDevice:LinkUp(0xe453e0) 13.1949s WifiNetDevice:LinkUp(): link changed 13.259s WifiNetDevice:LinkDown(0xe42840) 13.259s WifiNetDevice:LinkDown(): link changed 13.2596s WifiNetDevice:LinkUp(0xe42840) 13.2596s WifiNetDevice:LinkUp(): link changed 13.3576s WifiNetDevice:LinkDown(0xe3fce0) 13.3576s WifiNetDevice:LinkDown(): link changed 13.3581s WifiNetDevice:LinkUp(0xe3fce0) 13.3581s WifiNetDevice:LinkUp(): link changed -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 04:41:25 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 07:41:25 -0400 Subject: [Ns-bugs] [Bug 367] WiFi STA netdevices flip-flopping In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=367 ------- Comment #1 from gjcarneiro at gmail.com 2008-09-24 07:41 ------- Created an attachment (id=261) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=261&action=view) patch to add logging and attempt to do some filtering -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 04:42:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 07:42:11 -0400 Subject: [Ns-bugs] [Bug 367] WiFi STA netdevices flip-flopping In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=367 ------- Comment #2 from gjcarneiro at gmail.com 2008-09-24 07:42 ------- (From update of attachment 261) This patch doesn't solve anything, it's just what I used to add the logging. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 05:48:04 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 08:48:04 -0400 Subject: [Ns-bugs] [Bug 367] WiFi APs should generate beacons by default In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=367 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|WiFi STA netdevices flip- |WiFi APs should generate |flopping |beacons by default ------- Comment #3 from gjcarneiro at gmail.com 2008-09-24 08:48 ------- *sigh* it turns out this is due to APs not sending beacons by default. I have to question the logic of this behaviour. This means that, by default, wifi stations will once per second see their wifi links go down and up, and ARP caches flushed, all due to the fact that wifi beacons are not generated. I think no one can question that lack of wifi beacons is a unrealistic scenario even if the standard allows it. Just go buy any access point and turn it on; you will see it generates beacons every 100ms by default. So I don't think NS 3 should have a different default behaviour. And please don't just mask this ugly default value in the wifi helper, it should be fixed in the low level class, since not everyone uses helpers for everything. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 08:43:13 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 11:43:13 -0400 Subject: [Ns-bugs] [Bug 365] TcpSocketImpl::Recv returns 0 without setting m_errno In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-24 11:43 ------- (In reply to comment #4) > How about returning a NULL "pointer" (Ptr ()) on error? > > Ptr p = socket->Recv (); > if (!p) > { > // check socket->GetErrno (); > } yes, we already do this. The question is: how do you handle EOF ? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 08:46:17 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 11:46:17 -0400 Subject: [Ns-bugs] [Bug 366] Packet is not thread-safe In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=366 ------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-09-24 11:46 ------- (In reply to comment #2) > It turns out I am not sure I am making that mistake any more. When you say: > > "you can't create a packet in a thread and pass it to another thread, even if > you forget about it in the first thread." > > Is this really 100% accurate? In my case, I have one thread doing simulation, yes, I believe that this is accurate. Removing entries from the global from one thread to create packets and adding entries in this cache from another thread to 'destroy' them can't be safe without serious thinking. > and the main thread doing GUI stuff. But I use a mutex in the GUI thread, so I > am sure that the simulation thread is suspended while I am operating on the > packet. Even if there is a global cache, I am pretty sure only one thread is > operating on that cache at any given time. that _might_ work. There are many ways to make that implementation thread-safe and I agree with your previous comment that adding locking would be most likely a mistake. We need to figure out a better way to avoid locking and ensure thread-safety. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 11:40:18 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 14:40:18 -0400 Subject: [Ns-bugs] [Bug 366] Packet is not thread-safe In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=366 ------- Comment #4 from craigdo at ee.washington.edu 2008-09-24 14:40 ------- > > Even if there is a global cache, I am pretty sure only one thread is > > operating on that cache at any given time. > that _might_ work. This depends on what kind of threads we're talking about. Any mucking about in the global cache has got to be atomic. Reference counting using Ptr will kill you as well. You can't pass a Ptr between threads because the act of "forgetting about it" can cause an error. If you have a thread model in which threads run to completion or to a Yield operation, this could work. If you have a kernel-type thread that is pre-empted halfway through some critical section anywhere in the packet code, you'll die a horrible death. I believe the answer is going to depend on the threading model. In the real-time simulator (which you can think of as a multi-threaded simulator), we allow the event code (which allows multiple threads to access events) to "borrow" a critical section from the simulator that does nothing in the non-multi-threaded case, but performs real mutual exclusion in the multi-threaded case. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Sep 24 14:17:47 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Wed, 24 Sep 2008 17:17:47 -0400 Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using SetSendCallback with heavy traffic In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 ------- Comment #8 from evensky at dancer.ca.sandia.gov 2008-09-24 17:17 ------- Created an attachment (id=262) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=262&action=view) Patch to add NetDevice::SetSendReadyCallback As a starting point for a eventual soln at the Socket level. This patch adds a callback members NetDevice::m_sendReadyCallback, of type NetDevice::SendReadyCallback, and a method to set it, NetDevice::SetSendReadyCallback. If the callback is defined, it is invoked when a Packet is removed from the Queue. net-device.h has a stub definition, and PointToPointNetDevice has a defn that does something. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 03:35:56 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 06:35:56 -0400 Subject: [Ns-bugs] [Bug 326] Always run regression tests with ./waf check In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=326 gjcarneiro at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|./waf --regression should |Always run regression tests |not exist |with ./waf check ------- Comment #4 from gjcarneiro at gmail.com 2008-09-25 06:35 ------- Re-titling bug with a better description. But I still don't like it. I'm not sure why this is being proposed for ns 3.2.1... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 06:09:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 09:09:07 -0400 Subject: [Ns-bugs] [Bug 362] "Test for possibly unreachable code-- please file a bug report if this is ever hit" In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=362 tomh at tomh.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ns-bugs at isi.edu Status|NEW |ASSIGNED ------- Comment #1 from tomh at tomh.org 2008-09-25 09:09 ------- I think I see the problem-- I'll take this bug. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 06:12:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 09:12:48 -0400 Subject: [Ns-bugs] [Bug 363] Socket::SetDataSentCallback has bool return value In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=363 ------- Comment #1 from tomh at tomh.org 2008-09-25 09:12 ------- What are you instead suggesting as the behavior? Here is the current rationale: * \returns whether or not this socket supports this callback. Note * that this is a non-standard socket call. Some socket * implementations in ns-3 may not support this call, so the * user should check this return value to confirm that the * callback is supported. Or, are you saying that now that Nsc supports it, everyone will? -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 06:33:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 09:33:28 -0400 Subject: [Ns-bugs] [Bug 364] how do I know if Socket::SetSendCallback works ? In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=364 ------- Comment #2 from tomh at tomh.org 2008-09-25 09:33 ------- I agree with Gustavo and seem to recall we discussed and agreed on this behavior back when the socket API was redone. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 08:24:48 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 11:24:48 -0400 Subject: [Ns-bugs] [Bug 363] Socket::SetDataSentCallback has bool return value In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=363 ------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-09-25 11:24 ------- 1) this method is non-virtual and the only implementation of this method returns true unconditionally. Effectively, our implementation is making the return value meaningless. 2) I can't imagine how _anyone_ would be unable to support this callback so, supporting it unconditionally makes sense, so, removing the return value seems like the only logical choice. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 08:26:11 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 11:26:11 -0400 Subject: [Ns-bugs] [Bug 326] Always run regression tests with ./waf check In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=326 mathieu.lacage at sophia.inria.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-09-25 11:26 ------- I am fine with closing this since it seems everyone agrees that the current behavior is desirable. marking INVALID. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 09:36:07 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 12:36:07 -0400 Subject: [Ns-bugs] [Bug 368] New: "Attribute name=net.ipv4.tcp_sack does not exist for this object" Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=368 Summary: "Attribute name=net.ipv4.tcp_sack does not exist for this object" Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: sam.jansen at gmail.com This bug is somewhere in the integration of NSC and ns-3, so I'm unsure which component it should go under. It's not obviously anything wrong with NSC itself. This is from an email thread forwarded by Tom to Florian and myself. I'm pasting the email exchange below: Yes, I tried that already, maybe I didn't express myself correctly, but it only works if I comment all attributes for 2.6.18 and 2.6.26, so in the tcp-nsc-zoo example for node 1 and 3 from the NodeList. So of I comment all the Config::Set () calls that have Ns3NscStack i get the following message: Attribute name=net.ipv4.tcp_sack does not exist for this object: tid=ns3::Ns3NscStack > Hrm. I don't understand why that would happen. > Can you please comment out all the Config::Set () calls > that have Ns3NscStack in it in the nsc-zoo example? > I'd like to see if it will fail for the 2.6.18 Config::Set, too, > or if the problem only occurs with the 2.6.26 stack. > > Also, does './waf --regression-tests=test-tcp-nsc-lfn --regression' > work? You should see this output: > ========== Running Regression Tests ========== > Synchronizing reference traces using Mercurial. > Pulling http://code.nsnam.org/ns-3-dev-ref-traces from repo. > PASS test-tcp-nsc-lfn > > In case you have problems with obtaining the reference traces (waf > should fetch them automatically), the file > 'tcp-nsc-lfn-0-0.pcap' that is generated with the nsc-lfn example > should have a size of 43033154 bytes, and an sha1sum of > 314bb198c14cf5d0254a1b1e34ccae6efe3c5aa3 (on x86-32). > > Florian > >> >>Yes gcc was the problem, it took a while to replace my gcc with 4.2 >>series, and now it seems that it works fine, I tried to run those two >>examples tcp-nsc-zoo and tcp-nsc-lfn and I just get errors trying to >>run tcp-nsc-zoo >> >> >>Attribute name=net.ipv4.tcp_sack does not exist for this object: >>tid=ns3::Ns3NscStack >>Command ['/root/ns-3-dev/build/debug/examples/tcp-nsc-zoo'] exited with code -11 >> >>And after I comment >>Config::Set ("/NodeList/1/$ns3::Ns3NscStack/net.ipv4.tcp_sack", >>StringValue ("0")); >> >>I get the same error for other attributes as well. >> >>And tcp-nsc-lfn works fine. >> >>Thank you for your help! >> >>Borislava >> >>- Hide quoted text - >>On 9/24/08, Sam Jansen wrote: >>> The error is actually a gcc bug. We can see the output here: >>> >>> linux-2.6.18/net/ipv4/ip_output.c: In function 'ip_build_and_send_pkt': >>> linux-2.6.18/net/ipv4/ip_output.c:90: sorry, unimplemented: inlining >>> failed in call to 'ip_send_check': function body not available >>> linux-2.6.18/net/ipv4/ip_output.c:152: sorry, unimplemented: called from >>> here >>> >>> I have seen this on gcc-4.0.3 (the default compiler on ubuntu 7.04 or >>> so) and also one other version of gcc that I forget. The only solution >>> is using a different version of gcc (I know that 3.4.x and 4.2.x work >>> at least). >>> >>> Borislava, are you in a situation where you can install a newer >>> version of gcc, or maybe you have other versions installed already? I >>> can advise on how to configure the NSC build with a different >>> compiler, a fairly recent feature (and designed at least in part >>> because of this exact bug). >>> >>> I see that the compiler you are using is a prerelease of a gcc 4.1 >>> version. If possible, I would suggest the gcc 4.2 series, which in my >>> experience is much stabler. Amusingly, using an old compiiler (3.4) >>> would actually solve this problem too. >>> >>> On Tue, Sep 23, 2008 at 7:47 PM, Tom Henderson wrote: >>>> Borislava, >>>> >>>> I'm guessing that the problem is missing kernel headers, but I have cc'ed >>>> Sam Jansen (developer of NSC) for confirmation. >>>> >>>> - Tom >>>> >>>> Borislava Gajic wrote: >>>>> >>>>> Platform is: >>>>> >>>>> Linux spock 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 i686 >>>>> i686 i386 GNU/Linux >>>>> >>>>> gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) >>>>> >>>>> Messages after I try to build: >>>>> >>>>> Entering directory `/home/ns-3-dev/build' >>>>> [209/512] cxx: src/core/callback-test.cc -> >>>>> build/debug/src/core/callback-test_1.o >>>>> [210/512] cxx: src/core/log.cc -> build/debug/src/core/log_1.o >>>>> [211/512] cxx: src/core/breakpoint.cc -> >>>>> build/debug/src/core/breakpoint_1.o >>>>> [212/512] cxx: src/core/type-id.cc -> build/debug/src/core/type-id_1.o >>>>> [213/512] cxx: src/core/attribute-list.cc -> >>>>> build/debug/src/core/attribute-list_1.o >>>>> [214/512] cxx: src/core/object-base.cc -> >>>>> build/debug/src/core/object-base_1.o >>>>> [215/512] cxx: src/core/ref-count-base.cc -> >>>>> build/debug/src/core/ref-count-base_1.o >>>>> [216/512] cxx: src/core/ptr.cc -> build/debug/src/core/ptr_1.o >>>>> [217/512] cxx: src/core/object.cc -> build/debug/src/core/object_1.o >>>>> [218/512] cxx: src/core/test.cc -> build/debug/src/core/test_1.o >>>>> [219/512] cxx: src/core/random-variable.cc -> >>>>> build/debug/src/core/random-variable_1.o >>>>> [220/512] cxx: src/core/rng-stream.cc -> >>>>> build/debug/src/core/rng-stream_1.o >>>>> [221/512] cxx: src/core/command-line.cc -> >>>>> build/debug/src/core/command-line_1.o >>>>> [222/512] cxx: src/core/type-name.cc -> >>>>> build/debug/src/core/type-name_1.o >>>>> [223/512] cxx: src/core/type-traits-test.cc -> >>>>> build/debug/src/core/type-traits-test_1.o >>>>> [224/512] cxx: src/core/attribute.cc -> >>>>> build/debug/src/core/attribute_1.o >>>>> [225/512] cxx: src/core/boolean.cc -> build/debug/src/core/boolean_1.o >>>>> [226/512] cxx: src/core/integer.cc -> build/debug/src/core/integer_1.o >>>>> [227/512] cxx: src/core/uinteger.cc -> build/debug/src/core/uinteger_1.o >>>>> [228/512] cxx: src/core/enum.cc -> build/debug/src/core/enum_1.o >>>>> [229/512] cxx: src/core/double.cc -> build/debug/src/core/double_1.o >>>>> [230/512] cxx: src/core/string.cc -> build/debug/src/core/string_1.o >>>>> [231/512] cxx: src/core/pointer.cc -> build/debug/src/core/pointer_1.o >>>>> [232/512] cxx: src/core/object-vector.cc -> >>>>> build/debug/src/core/object-vector_1.o >>>>> [233/512] cxx: src/core/attribute-test.cc -> >>>>> build/debug/src/core/attribute-test_1.o >>>>> [234/512] cxx: src/core/object-factory.cc -> >>>>> build/debug/src/core/object-factory_1.o >>>>> [235/512] cxx: src/core/global-value.cc -> >>>>> build/debug/src/core/global-value_1.o >>>>> [236/512] cxx: src/core/traced-callback.cc -> >>>>> build/debug/src/core/traced-callback_1.o >>>>> [237/512] cxx: src/core/trace-source-accessor.cc -> >>>>> build/debug/src/core/trace-source-accessor_1.o >>>>> [238/512] cxx: src/core/config.cc -> build/debug/src/core/config_1.o >>>>> [239/512] cxx: src/core/unix-system-wall-clock-ms.cc -> >>>>> build/debug/src/core/unix-system-wall-clock-ms_1.o >>>>> [240/512] cxx: src/core/unix-system-thread.cc -> >>>>> build/debug/src/core/unix-system-thread_1.o >>>>> [241/512] cxx: src/core/unix-system-mutex.cc -> >>>>> build/debug/src/core/unix-system-mutex_1.o >>>>> [242/512] cxx: src/core/unix-system-condition.cc -> >>>>> build/debug/src/core/unix-system-condition_1.o >>>>> [243/512] cxx: src/common/buffer.cc -> build/debug/src/common/buffer_1.o >>>>> [244/512] cxx: src/common/packet-metadata.cc -> >>>>> build/debug/src/common/packet-metadata_1.o >>>>> [245/512] cxx: src/common/packet-metadata-test.cc -> >>>>> build/debug/src/common/packet-metadata-test_1.o >>>>> [246/512] cxx: src/common/packet.cc -> build/debug/src/common/packet_1.o >>>>> [247/512] cxx: src/common/chunk.cc -> build/debug/src/common/chunk_1.o >>>>> [248/512] cxx: src/common/header.cc -> build/debug/src/common/header_1.o >>>>> [249/512] cxx: src/common/trailer.cc -> >>>>> build/debug/src/common/trailer_1.o >>>>> [250/512] cxx: src/common/pcap-writer.cc -> >>>>> build/debug/src/common/pcap-writer_1.o >>>>> [251/512] cxx: src/common/data-rate.cc -> >>>>> build/debug/src/common/data-rate_1.o >>>>> [252/512] cxx: src/common/error-model.cc -> >>>>> build/debug/src/common/error-model_1.o >>>>> [253/512] cxx: src/common/tag.cc -> build/debug/src/common/tag_1.o >>>>> [254/512] cxx: src/common/tag-list.cc -> >>>>> build/debug/src/common/tag-list_1.o >>>>> [255/512] cxx: src/common/tag-buffer.cc -> >>>>> build/debug/src/common/tag-buffer_1.o >>>>> [256/512] cxx: src/simulator/high-precision.cc -> >>>>> build/debug/src/simulator/high-precision_1.o >>>>> [257/512] cxx: src/simulator/time.cc -> >>>>> build/debug/src/simulator/time_1.o >>>>> [258/512] cxx: src/simulator/event-id.cc -> >>>>> build/debug/src/simulator/event-id_1.o >>>>> [259/512] cxx: src/simulator/scheduler.cc -> >>>>> build/debug/src/simulator/scheduler_1.o >>>>> [260/512] cxx: src/simulator/list-scheduler.cc -> >>>>> build/debug/src/simulator/list-scheduler_1.o >>>>> [261/512] cxx: src/simulator/map-scheduler.cc -> >>>>> build/debug/src/simulator/map-scheduler_1.o >>>>> [262/512] cxx: src/simulator/heap-scheduler.cc -> >>>>> build/debug/src/simulator/heap-scheduler_1.o >>>>> [263/512] cxx: src/simulator/event-impl.cc -> >>>>> build/debug/src/simulator/event-impl_1.o >>>>> [264/512] cxx: src/simulator/simulator.cc -> >>>>> build/debug/src/simulator/simulator_1.o >>>>> [265/512] cxx: src/simulator/default-simulator-impl.cc -> >>>>> build/debug/src/simulator/default-simulator-impl_1.o >>>>> [266/512] cxx: src/simulator/timer.cc -> >>>>> build/debug/src/simulator/timer_1.o >>>>> [267/512] cxx: src/simulator/watchdog.cc -> >>>>> build/debug/src/simulator/watchdog_1.o >>>>> [268/512] cxx: src/simulator/synchronizer.cc -> >>>>> build/debug/src/simulator/synchronizer_1.o >>>>> [269/512] cxx: src/simulator/high-precision-128.cc -> >>>>> build/debug/src/simulator/high-precision-128_1.o >>>>> [270/512] cxx: src/simulator/cairo-wideint.c -> >>>>> build/debug/src/simulator/cairo-wideint_1.o >>>>> [271/512] cxx: src/simulator/realtime-simulator-impl.cc -> >>>>> build/debug/src/simulator/realtime-simulator-impl_1.o >>>>> [272/512] cxx: src/simulator/wall-clock-synchronizer.cc -> >>>>> build/debug/src/simulator/wall-clock-synchronizer_1.o >>>>> [273/512] cxx: src/contrib/event-garbage-collector.cc -> >>>>> build/debug/src/contrib/event-garbage-collector_1.o >>>>> [274/512] cxx: src/contrib/gnuplot.cc -> >>>>> build/debug/src/contrib/gnuplot_1.o >>>>> [275/512] cxx: src/contrib/delay-jitter-estimation.cc -> >>>>> build/debug/src/contrib/delay-jitter-estimation_1.o >>>>> [276/512] cxx: src/contrib/attribute-iterator.cc -> >>>>> build/debug/src/contrib/attribute-iterator_1.o >>>>> [277/512] cxx: src/contrib/config-store.cc -> >>>>> build/debug/src/contrib/config-store_1.o >>>>> [278/512] cxx: src/node/address.cc -> build/debug/src/node/address_1.o >>>>> [279/512] cxx: src/node/mac48-address.cc -> >>>>> build/debug/src/node/mac48-address_1.o >>>>> [280/512] cxx: src/node/mac64-address.cc -> >>>>> build/debug/src/node/mac64-address_1.o >>>>> [281/512] cxx: src/node/inet-socket-address.cc -> >>>>> build/debug/src/node/inet-socket-address_1.o >>>>> [282/512] cxx: src/node/packet-socket-address.cc -> >>>>> build/debug/src/node/packet-socket-address_1.o >>>>> [283/512] cxx: src/node/node.cc -> build/debug/src/node/node_1.o >>>>> [284/512] cxx: src/node/ipv4-address.cc -> >>>>> build/debug/src/node/ipv4-address_1.o >>>>> [285/512] cxx: src/node/ipv4-address-generator.cc -> >>>>> build/debug/src/node/ipv4-address-generator_1.o >>>>> [286/512] cxx: src/node/ipv4-header.cc -> >>>>> build/debug/src/node/ipv4-header_1.o >>>>> [287/512] cxx: src/node/net-device.cc -> >>>>> build/debug/src/node/net-device_1.o >>>>> [288/512] cxx: src/node/address-utils.cc -> >>>>> build/debug/src/node/address-utils_1.o >>>>> [289/512] cxx: src/node/llc-snap-header.cc -> >>>>> build/debug/src/node/llc-snap-header_1.o >>>>> [290/512] cxx: src/node/ethernet-header.cc -> >>>>> build/debug/src/node/ethernet-header_1.o >>>>> [291/512] cxx: src/node/ethernet-trailer.cc -> >>>>> build/debug/src/node/ethernet-trailer_1.o >>>>> [292/512] cxx: src/node/ipv4-route.cc -> >>>>> build/debug/src/node/ipv4-route_1.o >>>>> [293/512] cxx: src/node/queue.cc -> build/debug/src/node/queue_1.o >>>>> [294/512] cxx: src/node/drop-tail-queue.cc -> >>>>> build/debug/src/node/drop-tail-queue_1.o >>>>> [295/512] cxx: src/node/channel.cc -> build/debug/src/node/channel_1.o >>>>> [296/512] cxx: src/node/node-list.cc -> >>>>> build/debug/src/node/node-list_1.o >>>>> [297/512] cxx: src/node/socket.cc -> build/debug/src/node/socket_1.o >>>>> [298/512] cxx: src/node/socket-factory.cc -> >>>>> build/debug/src/node/socket-factory_1.o >>>>> [299/512] cxx: src/node/packet-socket-factory.cc -> >>>>> build/debug/src/node/packet-socket-factory_1.o >>>>> [300/512] cxx: src/node/packet-socket.cc -> >>>>> build/debug/src/node/packet-socket_1.o >>>>> [301/512] cxx: src/node/udp-socket.cc -> >>>>> build/debug/src/node/udp-socket_1.o >>>>> [302/512] cxx: src/node/udp-socket-factory.cc -> >>>>> build/debug/src/node/udp-socket-factory_1.o >>>>> [303/512] cxx: src/node/tcp-socket.cc -> >>>>> build/debug/src/node/tcp-socket_1.o >>>>> [304/512] cxx: src/node/tcp-socket-factory.cc -> >>>>> build/debug/src/node/tcp-socket-factory_1.o >>>>> [305/512] cxx: src/node/ipv4.cc -> build/debug/src/node/ipv4_1.o >>>>> [306/512] cxx: src/node/application.cc -> >>>>> build/debug/src/node/application_1.o >>>>> [307/512] cxx: src/node/simple-channel.cc -> >>>>> build/debug/src/node/simple-channel_1.o >>>>> [308/512] cxx: src/node/simple-net-device.cc -> >>>>> build/debug/src/node/simple-net-device_1.o >>>>> [309/512] cxx: src/internet-stack/internet-stack.cc -> >>>>> build/debug/src/internet-stack/internet-stack_1.o >>>>> [310/512] cxx: src/internet-stack/ipv4-l4-protocol.cc -> >>>>> build/debug/src/internet-stack/ipv4-l4-protocol_1.o >>>>> [311/512] cxx: src/internet-stack/udp-header.cc -> >>>>> build/debug/src/internet-stack/udp-header_1.o >>>>> [312/512] cxx: src/internet-stack/tcp-header.cc -> >>>>> build/debug/src/internet-stack/tcp-header_1.o >>>>> [313/512] cxx: src/internet-stack/ipv4-checksum.cc -> >>>>> build/debug/src/internet-stack/ipv4-checksum_1.o >>>>> [314/512] cxx: src/internet-stack/ipv4-interface.cc -> >>>>> build/debug/src/internet-stack/ipv4-interface_1.o >>>>> [315/512] cxx: src/internet-stack/ipv4-l3-protocol.cc -> >>>>> build/debug/src/internet-stack/ipv4-l3-protocol_1.o >>>>> [316/512] cxx: src/internet-stack/ipv4-static-routing.cc -> >>>>> build/debug/src/internet-stack/ipv4-static-routing_1.o >>>>> [317/512] cxx: src/internet-stack/ipv4-end-point.cc -> >>>>> build/debug/src/internet-stack/ipv4-end-point_1.o >>>>> [318/512] cxx: src/internet-stack/udp-l4-protocol.cc -> >>>>> build/debug/src/internet-stack/udp-l4-protocol_1.o >>>>> [319/512] cxx: src/internet-stack/tcp-l4-protocol.cc -> >>>>> build/debug/src/internet-stack/tcp-l4-protocol_1.o >>>>> [320/512] cxx: src/internet-stack/arp-header.cc -> >>>>> build/debug/src/internet-stack/arp-header_1.o >>>>> [321/512] cxx: src/internet-stack/arp-cache.cc -> >>>>> build/debug/src/internet-stack/arp-cache_1.o >>>>> [322/512] cxx: src/internet-stack/arp-ipv4-interface.cc -> >>>>> build/debug/src/internet-stack/arp-ipv4-interface_1.o >>>>> [323/512] cxx: src/internet-stack/arp-l3-protocol.cc -> >>>>> build/debug/src/internet-stack/arp-l3-protocol_1.o >>>>> [324/512] cxx: src/internet-stack/ipv4-loopback-interface.cc -> >>>>> build/debug/src/internet-stack/ipv4-loopback-interface_1.o >>>>> [325/512] cxx: src/internet-stack/udp-socket-impl.cc -> >>>>> build/debug/src/internet-stack/udp-socket-impl_1.o >>>>> [326/512] cxx: src/internet-stack/tcp-socket-impl.cc -> >>>>> build/debug/src/internet-stack/tcp-socket-impl_1.o >>>>> [327/512] cxx: src/internet-stack/ipv4-end-point-demux.cc -> >>>>> build/debug/src/internet-stack/ipv4-end-point-demux_1.o >>>>> [328/512] cxx: src/internet-stack/ipv4-impl.cc -> >>>>> build/debug/src/internet-stack/ipv4-impl_1.o >>>>> [329/512] cxx: src/internet-stack/udp-socket-factory-impl.cc -> >>>>> build/debug/src/internet-stack/udp-socket-factory-impl_1.o >>>>> [330/512] cxx: src/internet-stack/tcp-socket-factory-impl.cc -> >>>>> build/debug/src/internet-stack/tcp-socket-factory-impl_1.o >>>>> [331/512] cxx: src/internet-stack/pending-data.cc -> >>>>> build/debug/src/internet-stack/pending-data_1.o >>>>> [332/512] cxx: src/internet-stack/sequence-number.cc -> >>>>> build/debug/src/internet-stack/sequence-number_1.o >>>>> [333/512] cxx: src/internet-stack/rtt-estimator.cc -> >>>>> build/debug/src/internet-stack/rtt-estimator_1.o >>>>> [334/512] cxx: src/internet-stack/nsc-tcp-socket-impl.cc -> >>>>> build/debug/src/internet-stack/nsc-tcp-socket-impl_1.o >>>>> [335/512] cxx: src/internet-stack/nsc-tcp-l4-protocol.cc -> >>>>> build/debug/src/internet-stack/nsc-tcp-l4-protocol_1.o >>>>> [336/512] cxx: src/internet-stack/nsc-tcp-socket-factory-impl.cc -> >>>>> build/debug/src/internet-stack/nsc-tcp-socket-factory-impl_1.o >>>>> [337/512] cxx: src/internet-stack/nsc-sysctl.cc -> >>>>> build/debug/src/internet-stack/nsc-sysctl_1.o >>>>> [338/512] 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 >>>>> [339/512] cxx: src/devices/point-to-point/point-to-point-channel.cc -> >>>>> build/debug/src/devices/point-to-point/point-to-point-channel_1.o >>>>> [340/512] cxx: src/devices/point-to-point/point-to-point-test.cc -> >>>>> build/debug/src/devices/point-to-point/point-to-point-test_1.o >>>>> [341/512] cxx: src/devices/point-to-point/ppp-header.cc -> >>>>> build/debug/src/devices/point-to-point/ppp-header_1.o >>>>> [342/512] cxx: src/devices/csma/backoff.cc -> >>>>> build/debug/src/devices/csma/backoff_1.o >>>>> [343/512] cxx: src/devices/csma/csma-net-device.cc -> >>>>> build/debug/src/devices/csma/csma-net-device_1.o >>>>> [344/512] cxx: src/devices/csma/csma-channel.cc -> >>>>> build/debug/src/devices/csma/csma-channel_1.o >>>>> [345/512] cxx: src/applications/onoff/onoff-application.cc -> >>>>> build/debug/src/applications/onoff/onoff-application_1.o >>>>> [346/512] cxx: src/applications/packet-sink/packet-sink.cc -> >>>>> build/debug/src/applications/packet-sink/packet-sink_1.o >>>>> [347/512] cxx: src/applications/udp-echo/udp-echo-client.cc -> >>>>> build/debug/src/applications/udp-echo/udp-echo-client_1.o >>>>> [348/512] cxx: src/applications/udp-echo/udp-echo-server.cc -> >>>>> build/debug/src/applications/udp-echo/udp-echo-server_1.o >>>>> [349/512] cxx: src/routing/olsr/olsr-header.cc -> >>>>> build/debug/src/routing/olsr/olsr-header_1.o >>>>> [350/512] cxx: src/routing/olsr/olsr-state.cc -> >>>>> build/debug/src/routing/olsr/olsr-state_1.o >>>>> [351/512] cxx: src/routing/olsr/routing-table.cc -> >>>>> build/debug/src/routing/olsr/routing-table_1.o >>>>> [352/512] cxx: src/routing/olsr/olsr-agent.cc -> >>>>> build/debug/src/routing/olsr/olsr-agent_1.o >>>>> [353/512] cxx: src/routing/olsr/olsr-agent-impl.cc -> >>>>> build/debug/src/routing/olsr/olsr-agent-impl_1.o >>>>> [354/512] cxx: src/routing/global-routing/global-router-interface.cc -> >>>>> build/debug/src/routing/global-routing/global-router-interface_1.o >>>>> [355/512] cxx: src/routing/global-routing/global-route-manager.cc -> >>>>> build/debug/src/routing/global-routing/global-route-manager_1.o >>>>> [356/512] cxx: src/routing/global-routing/global-route-manager-impl.cc -> >>>>> build/debug/src/routing/global-routing/global-route-manager-impl_1.o >>>>> [357/512] cxx: src/routing/global-routing/candidate-queue.cc -> >>>>> build/debug/src/routing/global-routing/candidate-queue_1.o >>>>> [358/512] cxx: src/mobility/vector.cc -> >>>>> build/debug/src/mobility/vector_1.o >>>>> [359/512] cxx: src/mobility/hierarchical-mobility-model.cc -> >>>>> build/debug/src/mobility/hierarchical-mobility-model_1.o >>>>> [360/512] cxx: src/mobility/mobility-model.cc -> >>>>> build/debug/src/mobility/mobility-model_1.o >>>>> [361/512] cxx: src/mobility/position-allocator.cc -> >>>>> build/debug/src/mobility/position-allocator_1.o >>>>> [362/512] cxx: src/mobility/rectangle.cc -> >>>>> build/debug/src/mobility/rectangle_1.o >>>>> [363/512] cxx: src/mobility/static-mobility-model.cc -> >>>>> build/debug/src/mobility/static-mobility-model_1.o >>>>> [364/512] cxx: src/mobility/static-speed-helper.cc -> >>>>> build/debug/src/mobility/static-speed-helper_1.o >>>>> [365/512] cxx: src/mobility/static-speed-mobility-model.cc -> >>>>> build/debug/src/mobility/static-speed-mobility-model_1.o >>>>> [366/512] cxx: src/mobility/random-waypoint-mobility-model.cc -> >>>>> build/debug/src/mobility/random-waypoint-mobility-model_1.o >>>>> [367/512] cxx: src/mobility/random-walk-2d-mobility-model.cc -> >>>>> build/debug/src/mobility/random-walk-2d-mobility-model_1.o >>>>> [368/512] cxx: src/mobility/random-direction-2d-mobility-model.cc -> >>>>> build/debug/src/mobility/random-direction-2d-mobility-model_1.o >>>>> [369/512] cxx: src/devices/wifi/propagation-delay-model.cc -> >>>>> build/debug/src/devices/wifi/propagation-delay-model_1.o >>>>> [370/512] cxx: src/devices/wifi/propagation-loss-model.cc -> >>>>> build/debug/src/devices/wifi/propagation-loss-model_1.o >>>>> [371/512] cxx: src/devices/wifi/composite-propagation-loss-model.cc -> >>>>> build/debug/src/devices/wifi/composite-propagation-loss-model_1.o >>>>> [372/512] cxx: src/devices/wifi/jakes-propagation-loss-model.cc -> >>>>> build/debug/src/devices/wifi/jakes-propagation-loss-model_1.o >>>>> [373/512] cxx: src/devices/wifi/wifi-channel.cc -> >>>>> build/debug/src/devices/wifi/wifi-channel_1.o >>>>> [374/512] cxx: src/devices/wifi/wifi-mode.cc -> >>>>> build/debug/src/devices/wifi/wifi-mode_1.o >>>>> [375/512] cxx: src/devices/wifi/ssid.cc -> >>>>> build/debug/src/devices/wifi/ssid_1.o >>>>> [376/512] cxx: src/devices/wifi/wifi-phy.cc -> >>>>> build/debug/src/devices/wifi/wifi-phy_1.o >>>>> [377/512] cxx: src/devices/wifi/wifi-mac-header.cc -> >>>>> build/debug/src/devices/wifi/wifi-mac-header_1.o >>>>> [378/512] cxx: src/devices/wifi/wifi-mac-trailer.cc -> >>>>> build/debug/src/devices/wifi/wifi-mac-trailer_1.o >>>>> [379/512] cxx: src/devices/wifi/mac-low.cc -> >>>>> build/debug/src/devices/wifi/mac-low_1.o >>>>> [380/512] cxx: src/devices/wifi/wifi-mac-queue.cc -> >>>>> build/debug/src/devices/wifi/wifi-mac-queue_1.o >>>>> [381/512] cxx: src/devices/wifi/mac-tx-middle.cc -> >>>>> build/debug/src/devices/wifi/mac-tx-middle_1.o >>>>> [382/512] cxx: src/devices/wifi/mac-rx-middle.cc -> >>>>> build/debug/src/devices/wifi/mac-rx-middle_1.o >>>>> [383/512] cxx: src/devices/wifi/dca-txop.cc -> >>>>> build/debug/src/devices/wifi/dca-txop_1.o >>>>> [384/512] cxx: src/devices/wifi/supported-rates.cc -> >>>>> build/debug/src/devices/wifi/supported-rates_1.o >>>>> [385/512] cxx: src/devices/wifi/capability-information.cc -> >>>>> build/debug/src/devices/wifi/capability-information_1.o >>>>> [386/512] cxx: src/devices/wifi/status-code.cc -> >>>>> build/debug/src/devices/wifi/status-code_1.o >>>>> [387/512] cxx: src/devices/wifi/mgt-headers.cc -> >>>>> build/debug/src/devices/wifi/mgt-headers_1.o >>>>> [388/512] cxx: src/devices/wifi/random-stream.cc -> >>>>> build/debug/src/devices/wifi/random-stream_1.o >>>>> [389/512] cxx: src/devices/wifi/dcf-manager.cc -> >>>>> build/debug/src/devices/wifi/dcf-manager_1.o >>>>> [390/512] cxx: src/devices/wifi/dcf-manager-test.cc -> >>>>> build/debug/src/devices/wifi/dcf-manager-test_1.o >>>>> [391/512] cxx: src/devices/wifi/wifi-mac.cc -> >>>>> build/debug/src/devices/wifi/wifi-mac_1.o >>>>> [392/512] cxx: src/devices/wifi/wifi-remote-station-manager.cc -> >>>>> build/debug/src/devices/wifi/wifi-remote-station-manager_1.o >>>>> [393/512] cxx: src/devices/wifi/adhoc-wifi-mac.cc -> >>>>> build/debug/src/devices/wifi/adhoc-wifi-mac_1.o >>>>> [394/512] cxx: src/devices/wifi/nqap-wifi-mac.cc -> >>>>> build/debug/src/devices/wifi/nqap-wifi-mac_1.o >>>>> [395/512] cxx: src/devices/wifi/nqsta-wifi-mac.cc -> >>>>> build/debug/src/devices/wifi/nqsta-wifi-mac_1.o >>>>> [396/512] cxx: src/devices/wifi/wifi-net-device.cc -> >>>>> build/debug/src/devices/wifi/wifi-net-device_1.o >>>>> [397/512] cxx: src/devices/wifi/arf-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/arf-wifi-manager_1.o >>>>> [398/512] cxx: src/devices/wifi/aarf-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/aarf-wifi-manager_1.o >>>>> [399/512] cxx: src/devices/wifi/ideal-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/ideal-wifi-manager_1.o >>>>> [400/512] cxx: src/devices/wifi/amrr-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/amrr-wifi-manager_1.o >>>>> [401/512] cxx: src/devices/wifi/onoe-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/onoe-wifi-manager_1.o >>>>> [402/512] cxx: src/devices/wifi/rraa-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/rraa-wifi-manager_1.o >>>>> [403/512] cxx: src/devices/wifi/constant-rate-wifi-manager.cc -> >>>>> build/debug/src/devices/wifi/constant-rate-wifi-manager_1.o >>>>> [404/512] cxx: src/devices/wifi/wifi-test.cc -> >>>>> build/debug/src/devices/wifi/wifi-test_1.o >>>>> [405/512] cxx: src/helper/node-container.cc -> >>>>> build/debug/src/helper/node-container_1.o >>>>> [406/512] cxx: src/helper/net-device-container.cc -> >>>>> build/debug/src/helper/net-device-container_1.o >>>>> [407/512] cxx: src/helper/wifi-helper.cc -> >>>>> build/debug/src/helper/wifi-helper_1.o >>>>> [408/512] cxx: src/helper/olsr-helper.cc -> >>>>> build/debug/src/helper/olsr-helper_1.o >>>>> [409/512] cxx: src/helper/static-multicast-route-helper.cc -> >>>>> build/debug/src/helper/static-multicast-route-helper_1.o >>>>> [410/512] cxx: src/helper/point-to-point-helper.cc -> >>>>> build/debug/src/helper/point-to-point-helper_1.o >>>>> [411/512] cxx: src/helper/csma-helper.cc -> >>>>> build/debug/src/helper/csma-helper_1.o >>>>> [412/512] cxx: src/helper/mobility-helper.cc -> >>>>> build/debug/src/helper/mobility-helper_1.o >>>>> [413/512] cxx: src/helper/ns2-mobility-helper.cc -> >>>>> build/debug/src/helper/ns2-mobility-helper_1.o >>>>> [414/512] cxx: src/helper/ipv4-address-helper.cc -> >>>>> build/debug/src/helper/ipv4-address-helper_1.o >>>>> [415/512] cxx: src/helper/internet-stack-helper.cc -> >>>>> build/debug/src/helper/internet-stack-helper_1.o >>>>> [416/512] cxx: src/helper/application-container.cc -> >>>>> build/debug/src/helper/application-container_1.o >>>>> [417/512] cxx: src/helper/on-off-helper.cc -> >>>>> build/debug/src/helper/on-off-helper_1.o >>>>> [418/512] cxx: src/helper/packet-sink-helper.cc -> >>>>> build/debug/src/helper/packet-sink-helper_1.o >>>>> [419/512] cxx: src/helper/packet-socket-helper.cc -> >>>>> build/debug/src/helper/packet-socket-helper_1.o >>>>> [420/512] cxx: src/helper/ipv4-interface-container.cc -> >>>>> build/debug/src/helper/ipv4-interface-container_1.o >>>>> [421/512] cxx: src/helper/udp-echo-helper.cc -> >>>>> build/debug/src/helper/udp-echo-helper_1.o >>>>> [422/512] cxx: src/helper/bridge-helper.cc -> >>>>> build/debug/src/helper/bridge-helper_1.o >>>>> [423/512] cxx: src/devices/bridge/bridge-net-device.cc -> >>>>> build/debug/src/devices/bridge/bridge-net-device_1.o >>>>> [424/512] cxx: src/devices/bridge/bridge-channel.cc -> >>>>> build/debug/src/devices/bridge/bridge-channel_1.o >>>>> [425/512] cxx: src/contrib/stats/data-calculator.cc -> >>>>> build/debug/src/contrib/stats/data-calculator_1.o >>>>> [426/512] cxx: src/contrib/stats/packet-data-calculators.cc -> >>>>> build/debug/src/contrib/stats/packet-data-calculators_1.o >>>>> [427/512] cxx: src/contrib/stats/time-data-calculators.cc -> >>>>> build/debug/src/contrib/stats/time-data-calculators_1.o >>>>> [428/512] cxx: src/contrib/stats/data-output-interface.cc -> >>>>> build/debug/src/contrib/stats/data-output-interface_1.o >>>>> [429/512] cxx: src/contrib/stats/omnet-data-output.cc -> >>>>> build/debug/src/contrib/stats/omnet-data-output_1.o >>>>> [430/512] cxx: src/contrib/stats/data-collector.cc -> >>>>> build/debug/src/contrib/stats/data-collector_1.o >>>>> [431/512] cxx: samples/main-attribute-value.cc -> >>>>> build/debug/samples/main-attribute-value_1.o >>>>> [432/512] cxx: samples/main-callback.cc -> >>>>> build/debug/samples/main-callback_2.o >>>>> [433/512] cxx: samples/main-simulator.cc -> >>>>> build/debug/samples/main-simulator_3.o >>>>> [434/512] cxx: samples/main-packet-header.cc -> >>>>> build/debug/samples/main-packet-header_4.o >>>>> [435/512] cxx: samples/main-packet-tag.cc -> >>>>> build/debug/samples/main-packet-tag_5.o >>>>> [436/512] cxx: samples/main-test.cc -> build/debug/samples/main-test_6.o >>>>> [437/512] cxx: samples/main-simple.cc -> >>>>> build/debug/samples/main-simple_7.o >>>>> [438/512] cxx: samples/main-grid-topology.cc -> >>>>> build/debug/samples/main-grid-topology_8.o >>>>> [439/512] cxx: samples/main-random-topology.cc -> >>>>> build/debug/samples/main-random-topology_9.o >>>>> [440/512] cxx: samples/main-random-walk.cc -> >>>>> build/debug/samples/main-random-walk_10.o >>>>> [441/512] cxx: samples/main-propagation-loss.cc -> >>>>> build/debug/samples/main-propagation-loss_11.o >>>>> [442/512] cxx: utils/run-tests.cc -> build/debug/utils/run-tests_1.o >>>>> [443/512] cxx: utils/bench-simulator.cc -> >>>>> build/debug/utils/bench-simulator_2.o >>>>> [444/512] cxx: utils/bench-packets.cc -> >>>>> build/debug/utils/bench-packets_3.o >>>>> [445/512] cxx: utils/print-introspected-doxygen.cc -> >>>>> build/debug/utils/print-introspected-doxygen_4.o >>>>> [446/512] cxx: examples/hello-simulator.cc -> >>>>> build/debug/examples/hello-simulator_1.o >>>>> [447/512] cxx: examples/mixed-wireless.cc -> >>>>> build/debug/examples/mixed-wireless_2.o >>>>> [448/512] cxx: examples/simple-global-routing.cc -> >>>>> build/debug/examples/simple-global-routing_3.o >>>>> [449/512] cxx: examples/simple-alternate-routing.cc -> >>>>> build/debug/examples/simple-alternate-routing_4.o >>>>> [450/512] cxx: examples/simple-error-model.cc -> >>>>> build/debug/examples/simple-error-model_5.o >>>>> [451/512] cxx: examples/csma-one-subnet.cc -> >>>>> build/debug/examples/csma-one-subnet_6.o >>>>> [452/512] cxx: examples/csma-bridge.cc -> >>>>> build/debug/examples/csma-bridge_7.o >>>>> [453/512] cxx: examples/udp-echo.cc -> build/debug/examples/udp-echo_8.o >>>>> [454/512] cxx: examples/realtime-udp-echo.cc -> >>>>> build/debug/examples/realtime-udp-echo_9.o >>>>> [455/512] cxx: examples/csma-broadcast.cc -> >>>>> build/debug/examples/csma-broadcast_10.o >>>>> [456/512] cxx: examples/csma-packet-socket.cc -> >>>>> build/debug/examples/csma-packet-socket_11.o >>>>> [457/512] cxx: examples/csma-multicast.cc -> >>>>> build/debug/examples/csma-multicast_12.o >>>>> [458/512] cxx: examples/mixed-global-routing.cc -> >>>>> build/debug/examples/mixed-global-routing_13.o >>>>> [459/512] cxx: examples/simple-point-to-point-olsr.cc -> >>>>> build/debug/examples/simple-point-to-point-olsr_14.o >>>>> [460/512] cxx: examples/tcp-large-transfer.cc -> >>>>> build/debug/examples/tcp-large-transfer_15.o >>>>> [461/512] cxx: examples/tcp-nsc-lfn.cc -> >>>>> build/debug/examples/tcp-nsc-lfn_16.o >>>>> [462/512] cxx: examples/tcp-nsc-zoo.cc -> >>>>> build/debug/examples/tcp-nsc-zoo_17.o >>>>> [463/512] cxx: examples/tcp-star-server.cc -> >>>>> build/debug/examples/tcp-star-server_18.o >>>>> [464/512] cxx: examples/wifi-adhoc.cc -> >>>>> build/debug/examples/wifi-adhoc_19.o >>>>> [465/512] cxx: examples/wifi-ap.cc -> build/debug/examples/wifi-ap_20.o >>>>> [466/512] cxx: examples/stats/wifi-example-sim.cc -> >>>>> build/debug/examples/stats/wifi-example-sim_1.o >>>>> [467/512] cxx: examples/stats/wifi-example-apps.cc -> >>>>> build/debug/examples/stats/wifi-example-apps_1.o >>>>> [468/512] cxx: examples/wifi-wired-bridging.cc -> >>>>> build/debug/examples/wifi-wired-bridging_21.o >>>>> [469/512] cxx: scratch/multiple-sources/simple-main.cc -> >>>>> build/debug/scratch/multiple-sources/simple-main_1.o >>>>> [470/512] cxx: scratch/multiple-sources/simple-simulation.cc -> >>>>> build/debug/scratch/multiple-sources/simple-simulation_1.o >>>>> [471/512] cxx: scratch/simple.cc -> build/debug/scratch/simple_2.o >>>>> [472/512] cxx_link: build/debug/src/core/callback-test_1.o >>>>> build/debug/src/core/log_1.o build/debug/src/core/breakpoint_1.o >>>>> build/debug/src/core/type-id_1.o build/debug/src/core/attribute-list_1.o >>>>> build/debug/src/core/object-base_1.o >>>>> build/debug/src/core/ref-count-base_1.o >>>>> build/debug/src/core/ptr_1.o build/debug/src/core/object_1.o >>>>> build/debug/src/core/test_1.o build/debug/src/core/random-variable_1.o >>>>> build/debug/src/core/rng-stream_1.o build/debug/src/core/command-line_1.o >>>>> build/debug/src/core/type-name_1.o >>>>> build/debug/src/core/type-traits-test_1.o >>>>> build/debug/src/core/attribute_1.o build/debug/src/core/boolean_1.o >>>>> build/debug/src/core/integer_1.o build/debug/src/core/uinteger_1.o >>>>> build/debug/src/core/enum_1.o build/debug/src/core/double_1.o >>>>> build/debug/src/core/string_1.o build/debug/src/core/pointer_1.o >>>>> build/debug/src/core/object-vector_1.o >>>>> build/debug/src/core/attribute-test_1.o >>>>> build/debug/src/core/object-factory_1.o >>>>> build/debug/src/core/global-value_1.o >>>>> build/debug/src/core/traced-callback_1.o >>>>> build/debug/src/core/trace-source-accessor_1.o >>>>> build/debug/src/core/config_1.o >>>>> build/debug/src/core/unix-system-wall-clock-ms_1.o >>>>> build/debug/src/core/unix-system-thread_1.o >>>>> build/debug/src/core/unix-system-mutex_1.o >>>>> build/debug/src/core/unix-system-condition_1.o >>>>> build/debug/src/simulator/high-precision_1.o >>>>> build/debug/src/simulator/time_1.o build/debug/src/simulator/event-id_1.o >>>>> build/debug/src/simulator/scheduler_1.o >>>>> build/debug/src/simulator/list-scheduler_1.o >>>>> build/debug/src/simulator/map-scheduler_1.o >>>>> build/debug/src/simulator/heap-scheduler_1.o >>>>> build/debug/src/simulator/event-impl_1.o >>>>> build/debug/src/simulator/simulator_1.o >>>>> build/debug/src/simulator/default-simulator-impl_1.o >>>>> build/debug/src/simulator/timer_1.o >>>>> build/debug/src/simulator/watchdog_1.o >>>>> build/debug/src/simulator/synchronizer_1.o >>>>> build/debug/src/simulator/high-precision-128_1.o >>>>> build/debug/src/simulator/cairo-wideint_1.o >>>>> build/debug/src/simulator/realtime-simulator-impl_1.o >>>>> build/debug/src/simulator/wall-clock-synchronizer_1.o >>>>> build/debug/src/common/buffer_1.o >>>>> build/debug/src/common/packet-metadata_1.o >>>>> build/debug/src/common/packet-metadata-test_1.o >>>>> build/debug/src/common/packet_1.o build/debug/src/common/chunk_1.o >>>>> build/debug/src/common/header_1.o build/debug/src/common/trailer_1.o >>>>> build/debug/src/common/pcap-writer_1.o >>>>> build/debug/src/common/data-rate_1.o >>>>> build/debug/src/common/error-model_1.o build/debug/src/common/tag_1.o >>>>> build/debug/src/common/tag-list_1.o build/debug/src/common/tag-buffer_1.o >>>>> build/debug/src/contrib/event-garbage-collector_1.o >>>>> build/debug/src/contrib/gnuplot_1.o >>>>> build/debug/src/contrib/delay-jitter-estimation_1.o >>>>> build/debug/src/contrib/attribute-iterator_1.o >>>>> build/debug/src/contrib/config-store_1.o build/debug/src/node/address_1.o >>>>> build/debug/src/node/mac48-address_1.o >>>>> build/debug/src/node/mac64-address_1.o >>>>> build/debug/src/node/inet-socket-address_1.o >>>>> build/debug/src/node/packet-socket-address_1.o >>>>> build/debug/src/node/node_1.o >>>>> build/debug/src/node/ipv4-address_1.o >>>>> build/debug/src/node/ipv4-address-generator_1.o >>>>> build/debug/src/node/ipv4-header_1.o build/debug/src/node/net-device_1.o >>>>> build/debug/src/node/address-utils_1.o >>>>> build/debug/src/node/llc-snap-header_1.o >>>>> build/debug/src/node/ethernet-header_1.o >>>>> build/debug/src/node/ethernet-trailer_1.o >>>>> build/debug/src/node/ipv4-route_1.o build/debug/src/node/queue_1.o >>>>> build/debug/src/node/drop-tail-queue_1.o build/debug/src/node/channel_1.o >>>>> build/debug/src/node/node-list_1.o build/debug/src/node/socket_1.o >>>>> build/debug/src/node/socket-factory_1.o >>>>> build/debug/src/node/packet-socket-factory_1.o >>>>> build/debug/src/node/packet-socket_1.o >>>>> build/debug/src/node/udp-socket_1.o >>>>> build/debug/src/node/udp-socket-factory_1.o >>>>> build/debug/src/node/tcp-socket_1.o >>>>> build/debug/src/node/tcp-socket-factory_1.o build/debug/src/node/ipv4_1.o >>>>> build/debug/src/node/application_1.o >>>>> build/debug/src/node/simple-channel_1.o >>>>> build/debug/src/node/simple-net-device_1.o >>>>> build/debug/src/internet-stack/internet-stack_1.o >>>>> build/debug/src/internet-stack/ipv4-l4-protocol_1.o >>>>> build/debug/src/internet-stack/udp-header_1.o >>>>> build/debug/src/internet-stack/tcp-header_1.o >>>>> build/debug/src/internet-stack/ipv4-checksum_1.o >>>>> build/debug/src/internet-stack/ipv4-interface_1.o >>>>> build/debug/src/internet-stack/ipv4-l3-protocol_1.o >>>>> build/debug/src/internet-stack/ipv4-static-routing_1.o >>>>> build/debug/src/internet-stack/ipv4-end-point_1.o >>>>> build/debug/src/internet-stack/udp-l4-protocol_1.o >>>>> build/debug/src/internet-stack/tcp-l4-protocol_1.o >>>>> build/debug/src/internet-stack/arp-header_1.o >>>>> build/debug/src/internet-stack/arp-cache_1.o >>>>> build/debug/src/internet-stack/arp-ipv4-interface_1.o >>>>> build/debug/src/internet-stack/arp-l3-protocol_1.o >>>>> build/debug/src/internet-stack/ipv4-loopback-interface_1.o >>>>> build/debug/src/internet-stack/udp-socket-impl_1.o >>>>> build/debug/src/internet-stack/tcp-socket-impl_1.o >>>>> build/debug/src/internet-stack/ipv4-end-point-demux_1.o >>>>> build/debug/src/internet-stack/ipv4-impl_1.o >>>>> build/debug/src/internet-stack/udp-socket-factory-impl_1.o >>>>> build/debug/src/internet-stack/tcp-socket-factory-impl_1.o >>>>> build/debug/src/internet-stack/pending-data_1.o >>>>> build/debug/src/internet-stack/sequence-number_1.o >>>>> build/debug/src/internet-stack/rtt-estimator_1.o >>>>> build/debug/src/internet-stack/nsc-tcp-socket-impl_1.o >>>>> build/debug/src/internet-stack/nsc-tcp-l4-protocol_1.o >>>>> build/debug/src/internet-stack/nsc-tcp-socket-factory-impl_1.o >>>>> build/debug/src/internet-stack/nsc-sysctl_1.o >>>>> build/debug/src/devices/point-to-point/point-to-point-net-device_1.o >>>>> build/debug/src/devices/point-to-point/point-to-point-channel_1.o >>>>> build/debug/src/devices/point-to-point/point-to-point-test_1.o >>>>> build/debug/src/devices/point-to-point/ppp-header_1.o >>>>> build/debug/src/devices/csma/backoff_1.o >>>>> build/debug/src/devices/csma/csma-net-device_1.o >>>>> build/debug/src/devices/csma/csma-channel_1.o >>>>> build/debug/src/applications/onoff/onoff-application_1.o >>>>> build/debug/src/applications/packet-sink/packet-sink_1.o >>>>> build/debug/src/applications/udp-echo/udp-echo-client_1.o >>>>> build/debug/src/applications/udp-echo/udp-echo-server_1.o >>>>> build/debug/src/routing/olsr/olsr-header_1.o >>>>> build/debug/src/routing/olsr/olsr-state_1.o >>>>> build/debug/src/routing/olsr/routing-table_1.o >>>>> build/debug/src/routing/olsr/olsr-agent_1.o >>>>> build/debug/src/routing/olsr/olsr-agent-impl_1.o >>>>> build/debug/src/routing/global-routing/global-router-interface_1.o >>>>> build/debug/src/routing/global-routing/global-route-manager_1.o >>>>> build/debug/src/routing/global-routing/global-route-manager-impl_1.o >>>>> build/debug/src/routing/global-routing/candidate-queue_1.o >>>>> build/debug/src/mobility/vector_1.o >>>>> build/debug/src/mobility/hierarchical-mobility-model_1.o >>>>> build/debug/src/mobility/mobility-model_1.o >>>>> build/debug/src/mobility/position-allocator_1.o >>>>> build/debug/src/mobility/rectangle_1.o >>>>> build/debug/src/mobility/static-mobility-model_1.o >>>>> build/debug/src/mobility/static-speed-helper_1.o >>>>> build/debug/src/mobility/static-speed-mobility-model_1.o >>>>> build/debug/src/mobility/random-waypoint-mobility-model_1.o >>>>> build/debug/src/mobility/random-walk-2d-mobility-model_1.o >>>>> build/debug/src/mobility/random-direction-2d-mobility-model_1.o >>>>> build/debug/src/devices/wifi/propagation-delay-model_1.o >>>>> build/debug/src/devices/wifi/propagation-loss-model_1.o >>>>> build/debug/src/devices/wifi/composite-propagation-loss-model_1.o >>>>> build/debug/src/devices/wifi/jakes-propagation-loss-model_1.o >>>>> build/debug/src/devices/wifi/wifi-channel_1.o >>>>> build/debug/src/devices/wifi/wifi-mode_1.o >>>>> build/debug/src/devices/wifi/ssid_1.o >>>>> build/debug/src/devices/wifi/wifi-phy_1.o >>>>> build/debug/src/devices/wifi/wifi-mac-header_1.o >>>>> build/debug/src/devices/wifi/wifi-mac-trailer_1.o >>>>> build/debug/src/devices/wifi/mac-low_1.o >>>>> build/debug/src/devices/wifi/wifi-mac-queue_1.o >>>>> build/debug/src/devices/wifi/mac-tx-middle_1.o >>>>> build/debug/src/devices/wifi/mac-rx-middle_1.o >>>>> build/debug/src/devices/wifi/dca-txop_1.o >>>>> build/debug/src/devices/wifi/supported-rates_1.o >>>>> build/debug/src/devices/wifi/capability-information_1.o >>>>> build/debug/src/devices/wifi/status-code_1.o >>>>> build/debug/src/devices/wifi/mgt-headers_1.o >>>>> build/debug/src/devices/wifi/random-stream_1.o >>>>> build/debug/src/devices/wifi/dcf-manager_1.o >>>>> build/debug/src/devices/wifi/dcf-manager-test_1.o >>>>> build/debug/src/devices/wifi/wifi-mac_1.o >>>>> build/debug/src/devices/wifi/wifi-remote-station-manager_1.o >>>>> build/debug/src/devices/wifi/adhoc-wifi-mac_1.o >>>>> build/debug/src/devices/wifi/nqap-wifi-mac_1.o >>>>> build/debug/src/devices/wifi/nqsta-wifi-mac_1.o >>>>> build/debug/src/devices/wifi/wifi-net-device_1.o >>>>> build/debug/src/devices/wifi/arf-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/aarf-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/ideal-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/amrr-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/onoe-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/rraa-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/constant-rate-wifi-manager_1.o >>>>> build/debug/src/devices/wifi/wifi-test_1.o >>>>> build/debug/src/helper/node-container_1.o >>>>> build/debug/src/helper/net-device-container_1.o >>>>> build/debug/src/helper/wifi-helper_1.o >>>>> build/debug/src/helper/olsr-helper_1.o >>>>> build/debug/src/helper/static-multicast-route-helper_1.o >>>>> build/debug/src/helper/point-to-point-helper_1.o >>>>> build/debug/src/helper/csma-helper_1.o >>>>> build/debug/src/helper/mobility-helper_1.o >>>>> build/debug/src/helper/ns2-mobility-helper_1.o >>>>> build/debug/src/helper/ipv4-address-helper_1.o >>>>> build/debug/src/helper/internet-stack-helper_1.o >>>>> build/debug/src/helper/application-container_1.o >>>>> build/debug/src/helper/on-off-helper_1.o >>>>> build/debug/src/helper/packet-sink-helper_1.o >>>>> build/debug/src/helper/packet-socket-helper_1.o >>>>> build/debug/src/helper/ipv4-interface-container_1.o >>>>> build/debug/src/helper/udp-echo-helper_1.o >>>>> build/debug/src/helper/bridge-helper_1.o >>>>> build/debug/src/devices/bridge/bridge-net-device_1.o >>>>> build/debug/src/devices/bridge/bridge-channel_1.o >>>>> build/debug/src/contrib/stats/data-calculator_1.o >>>>> build/debug/src/contrib/stats/packet-data-calculators_1.o >>>>> build/debug/src/contrib/stats/time-data-calculators_1.o >>>>> build/debug/src/contrib/stats/data-output-interface_1.o >>>>> build/debug/src/contrib/stats/omnet-data-output_1.o >>>>> build/debug/src/contrib/stats/data-collector_1.o -> build/debug/libns3.so >>>>> [473/512] cxx_link: build/debug/samples/main-callback_2.o -> >>>>> build/debug/samples/main-callback >>>>> [474/512] cxx_link: build/debug/samples/main-simulator_3.o -> >>>>> build/debug/samples/main-simulator >>>>> [475/512] cxx_link: build/debug/samples/main-packet-header_4.o -> >>>>> build/debug/samples/main-packet-header >>>>> [476/512] cxx_link: build/debug/samples/main-packet-tag_5.o -> >>>>> build/debug/samples/main-packet-tag >>>>> [477/512] cxx_link: build/debug/samples/main-test_6.o -> >>>>> build/debug/samples/main-test >>>>> [478/512] cxx_link: build/debug/samples/main-simple_7.o -> >>>>> build/debug/samples/main-simple >>>>> [479/512] cxx_link: build/debug/samples/main-grid-topology_8.o -> >>>>> build/debug/samples/main-grid-topology >>>>> [480/512] cxx_link: build/debug/samples/main-random-topology_9.o -> >>>>> build/debug/samples/main-random-topology >>>>> [481/512] cxx_link: build/debug/samples/main-random-walk_10.o -> >>>>> build/debug/samples/main-random-walk >>>>> [482/512] cxx_link: build/debug/samples/main-propagation-loss_11.o -> >>>>> build/debug/samples/main-propagation-loss >>>>> [483/512] cxx_link: build/debug/utils/run-tests_1.o -> >>>>> build/debug/utils/run-tests >>>>> [484/512] cxx_link: build/debug/utils/bench-simulator_2.o -> >>>>> build/debug/utils/bench-simulator >>>>> [485/512] cxx_link: build/debug/utils/bench-packets_3.o -> >>>>> build/debug/utils/bench-packets >>>>> [486/512] cxx_link: build/debug/utils/print-introspected-doxygen_4.o -> >>>>> build/debug/utils/print-introspected-doxygen >>>>> [487/512] cxx_link: build/debug/examples/hello-simulator_1.o -> >>>>> build/debug/examples/hello-simulator >>>>> [488/512] cxx_link: build/debug/examples/mixed-wireless_2.o -> >>>>> build/debug/examples/mixed-wireless >>>>> [489/512] cxx_link: build/debug/examples/simple-global-routing_3.o -> >>>>> build/debug/examples/simple-global-routing >>>>> [490/512] cxx_link: build/debug/examples/simple-alternate-routing_4.o -> >>>>> build/debug/examples/simple-alternate-routing >>>>> [491/512] cxx_link: build/debug/examples/simple-error-model_5.o -> >>>>> build/debug/examples/simple-error-model >>>>> [492/512] cxx_link: build/debug/examples/csma-one-subnet_6.o -> >>>>> build/debug/examples/csma-one-subnet >>>>> [493/512] cxx_link: build/debug/examples/csma-bridge_7.o -> >>>>> build/debug/examples/csma-bridge >>>>> [494/512] cxx_link: build/debug/examples/udp-echo_8.o -> >>>>> build/debug/examples/udp-echo >>>>> [495/512] cxx_link: build/debug/examples/realtime-udp-echo_9.o -> >>>>> build/debug/examples/realtime-udp-echo >>>>> [496/512] cxx_link: build/debug/examples/csma-broadcast_10.o -> >>>>> build/debug/examples/csma-broadcast >>>>> [497/512] cxx_link: build/debug/examples/csma-packet-socket_11.o -> >>>>> build/debug/examples/csma-packet-socket >>>>> [498/512] cxx_link: build/debug/examples/csma-multicast_12.o -> >>>>> build/debug/examples/csma-multicast >>>>> [499/512] cxx_link: build/debug/examples/mixed-global-routing_13.o -> >>>>> build/debug/examples/mixed-global-routing >>>>> [500/512] cxx_link: build/debug/examples/simple-point-to-point-olsr_14.o >>>>> -> build/debug/examples/simple-point-to-point-olsr >>>>> [501/512] cxx_link: build/debug/examples/tcp-large-transfer_15.o -> >>>>> build/debug/examples/tcp-large-transfer >>>>> [502/512] cxx_link: build/debug/examples/tcp-nsc-lfn_16.o -> >>>>> build/debug/examples/tcp-nsc-lfn >>>>> [503/512] cxx_link: build/debug/examples/tcp-nsc-zoo_17.o -> >>>>> build/debug/examples/tcp-nsc-zoo >>>>> [504/512] cxx_link: build/debug/examples/tcp-star-server_18.o -> >>>>> build/debug/examples/tcp-star-server >>>>> [505/512] cxx_link: build/debug/examples/wifi-adhoc_19.o -> >>>>> build/debug/examples/wifi-adhoc >>>>> [506/512] cxx_link: build/debug/examples/wifi-ap_20.o -> >>>>> build/debug/examples/wifi-ap >>>>> [507/512] cxx_link: build/debug/examples/stats/wifi-example-sim_1.o >>>>> build/debug/examples/stats/wifi-example-apps_1.o -> >>>>> build/debug/examples/stats/wifi-example-sim >>>>> [508/512] cxx_link: build/debug/examples/wifi-wired-bridging_21.o -> >>>>> build/debug/examples/wifi-wired-bridging >>>>> [509/512] cxx_link: build/debug/scratch/multiple-sources/simple-main_1.o >>>>> build/debug/scratch/multiple-sources/simple-simulation_1.o -> >>>>> build/debug/scratch/multiple-sources/multiple-sources >>>>> [510/512] cxx_link: build/debug/scratch/simple_2.o -> >>>>> build/debug/scratch/simple >>>>> [511/512] cxx_link: build/debug/samples/main-attribute-value_1.o -> >>>>> build/debug/samples/main-attribute-value >>>>> [512/512] scons: Reading SConscript files ... >>>>> Checking target architecure...(cached) x86 >>>>> scons: done reading SConscript files. >>>>> scons: Building targets ... >>>>> gcc -o linux-2.6.18/net/ipv4/ip_output.globalised.o -c -D__KERNEL__ -Wall >>>>> -Wstrict-prototypes -Wno-trigraphs -nostdinc -fno-inline -iwithprefix >>>>> include -DKBUILD_BASENAME=\"clnt\" -DKBUILD_MODNAME=\"nsc\" -DMODVERSIONS >>>>> -DEXPORT_SYMTAB -include linux/config.h -g -U__FreeBSD__ -D__linux__=1 >>>>> -Dlinux=1 -D__linux=1 -Ilinux-2.6.18/include >>>>> -Ilinux-2.6.18/include/asm/mach-default -Isim -Ilinux-2.6.18/nsc >>>>> -Ilinux-2.6.18/override linux-2.6.18/net/ipv4/ip_output.globalised.c >>>>> In file included from linux-2.6.18/include/linux/if_ether.h:112, >>>>> from linux-2.6.18/include/linux/netdevice.h:30, >>>>> from linux-2.6.18/net/ipv4/ip_output.c:62: >>>>> linux-2.6.18/include/linux/skbuff.h: In function 'skb_add_data': >>>>> linux-2.6.18/include/linux/skbuff.h:1203: warning: pointer targets in >>>>> passing argument 1 of 'csum_and_copy_from_user' differ in signedness >>>>> In file included from linux-2.6.18/include/net/inet_sock.h:25, >>>>> from linux-2.6.18/include/net/ip.h:30, >>>>> from linux-2.6.18/net/ipv4/ip_output.c:69: >>>>> linux-2.6.18/include/net/sock.h: In function 'skb_copy_to_page': >>>>> linux-2.6.18/include/net/sock.h:1070: warning: pointer targets in passing >>>>> argument 1 of 'csum_and_copy_from_user' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c: In function 'ip_build_and_send_pkt': >>>>> linux-2.6.18/net/ipv4/ip_output.c:90: sorry, unimplemented: inlining >>>>> failed in call to 'ip_send_check': function body not available >>>>> linux-2.6.18/net/ipv4/ip_output.c:152: sorry, unimplemented: called from >>>>> here >>>>> linux-2.6.18/net/ipv4/ip_output.c: In function 'ip_generic_getfrag': >>>>> linux-2.6.18/net/ipv4/ip_output.c:683: warning: pointer targets in >>>>> passing >>>>> argument 1 of 'memcpy_fromiovecend' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:687: warning: pointer targets in >>>>> passing >>>>> argument 1 of 'csum_partial_copy_fromiovecend' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:687: warning: pointer targets in >>>>> passing >>>>> argument 5 of 'csum_partial_copy_fromiovecend' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c: In function 'csum_page': >>>>> linux-2.6.18/net/ipv4/ip_output.c:700: warning: pointer targets in >>>>> passing >>>>> argument 1 of 'csum_partial' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c: In function 'ip_append_data': >>>>> linux-2.6.18/net/ipv4/ip_output.c:939: warning: pointer targets in >>>>> assignment differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:940: warning: pointer targets in >>>>> assignment differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:942: warning: pointer targets in >>>>> assignment differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:947: warning: pointer targets in >>>>> passing >>>>> argument 3 of 'skb_copy_and_csum_bits' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:982: warning: pointer targets in >>>>> passing >>>>> argument 2 of 'getfrag' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c: In function 'ip_append_page': >>>>> linux-2.6.18/net/ipv4/ip_output.c:1135: warning: pointer targets in >>>>> assignment differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:1138: warning: pointer targets in >>>>> assignment differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c:1143: warning: pointer targets in >>>>> passing argument 3 of 'skb_copy_and_csum_bits' differ in signedness >>>>> linux-2.6.18/net/ipv4/ip_output.c: In function 'ip_reply_glue_bits': >>>>> linux-2.6.18/net/ipv4/ip_output.c:1320: warning: pointer targets in >>>>> passing argument 2 of 'csum_partial_copy_nocheck' differ in signedness >>>>> scons: *** [linux-2.6.18/net/ipv4/ip_output.globalised.o] Error 1 >>>>> scons: building terminated because of errors. >>>>> Building NSC stack failed >>>>> >>>>> >>>>> >>>>> If you need more informations please contact me. >>>>> >>>>> Thank you for your help! >>>>> >>>>> Borislava >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Sep 23, 2008 at 5:27 PM, Tom Henderson >>>> > wrote: >>>>> >>>>> bg wrote: >>>>> >>>>> Thank you very much for your answer! >>>>> Today I tried to build NSC as it is explained in Manual, well >>>>> enabling >>>>> NSC went fine, and I have nsc directory with the contents you >>>>> listed >>>>> in Manual, but after trying to build everything I got and error >>>>> >>>>> [linux-2.6.18/net/ipv4/ip_output.globalized.o] Error 1 >>>>> building terminated because of errors. >>>>> Building NSC stack failed. >>>>> >>>>> Then I tried to find ip_output.globalized.o, but in the directory >>>>> there is just ip_output.globalized.c >>>>> >>>>> I can't find the reason why it doesn't make .o file out of it, I >>>>> checked for tcp_ output.globalized.c and .o and everything seems >>>>> fine. >>>>> >>>>> Any comment would be helpful! >>>>> >>>>> Thank you! >>>>> >>>>> >>>>> Hi, >>>>> When reporting a bug, can you please provide as much contextual >>>>> information as possible? >>>>> >>>>> Specifically, can you provide all of the build error output, such as >>>>> everything above these lines? >>>>> >>>>> > [linux-2.6.18/net/ipv4/ip_output.globalized.o] Error 1 >>>>> > building terminated because of errors. >>>>> > Building NSC stack failed. >>>>> >>>>> Also, which platform are you using? (type "uname -a" and send the >>>>> results) and also what version of gcc? (type "gcc -v") >>>>> >>>>> then, I might have some better idea what the problem is. >>>>> >>>>> - Tom >>>>> >>>>> >>>>> >>>>> On Sep 23, 7:12 am, Tom Henderson >>>> > wrote: >>>>> >>>>> Tom Henderson wrote: >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: bg [mailto:borislava.ga... at gmail.com >>>>> ] >>>>> Sent: Friday, September 19, 2008 05:09 AM >>>>> To: 'ns-3-users' >>>>> Subject: Network Simulation Cradle >>>>> Hi all, >>>>> I want to try out NSC for ns3, so far I couldn't >>>>> find a lot of >>>>> detailed documentation about it, since all available >>>>> tutorials >>>>> provided by WAND Network Research Group are mainly >>>>> for ns2. >>>>> Does anyone know some useful tutorial for NSC in >>>>> ns3, or some link >>>>> where it is better documented? >>>>> Thank you! >>>>> >>>>> See this documentation page, for >>>>> starters:http://www.nsnam.org/docs/release/manual.html#SEC86 >>>>> >>>>> - Tom >>>>> >>>>> >>>>> >>>> >>>> >>> -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Sep 25 09:50:28 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Thu, 25 Sep 2008 12:50:28 -0400 Subject: [Ns-bugs] [Bug 368] "Attribute name=net.ipv4.tcp_sack does not exist for this object" In-Reply-To: Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=368 ------- Comment #1 from fw-ns3 at strlen.de 2008-09-25 12:50 ------- It might be a good idea to enable printk output during the stack initialization phase; this will show if ns-3 queries nsc about the attribute list. Currently, one needs to edit src/internet-stack/nsc-tcp-l4-protocol.cc And change this (in NscTcpL4Protocol::SetNode) from m_softTimer.SetDelay (MilliSeconds (1000/hzval)); m_nscStack->init(hzval); // This enables stack and NSC debug messages // m_nscStack->set_diagnostic(1000); to: m_softTimer.SetDelay (MilliSeconds (1000/hzval)); m_nscStack->set_diagnostic(10); m_nscStack->init(hzval); I'll see about making this an attribute. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Sep 30 07:44:00 2008 From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu) Date: Tue, 30 Sep 2008 10:44:00 -0400 Subject: [Ns-bugs] [Bug 369] New: RandomVariable: GetValue ->GenerateValue ? Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=369 Summary: RandomVariable: GetValue ->GenerateValue ? Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: gjcarneiro at gmail.com Real story. I was teaching a colleague to use random variables for scheduling, with code like this: Time t = Seconds (0); ExponentialVariable rng (5.14); for (n = 0; n < 10000; n++) { Schedule (t, ...); t += rng.GetValue (); } He asks, "shouldn't the 'ExponentialVariable rng (5.14)' part be inside the for loop?". I had to explain to him that rng.GetValue () actually generates a new value each time it is called. We came to the conclusion that perhaps GenerateValue () would be a better method name. So I leave here that thought for your consideration... -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.