From code at nsnam.ece.gatech.edu Thu Apr 1 10:24:59 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Thu, 1 Apr 2010 13:24:59 -0400 Subject: [Ns-bugs] [Bug 855] New: waf dies badly when switching from debug to optimized build or vice versa Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=855 Summary: waf dies badly when switching from debug to optimized build or vice versa Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P4 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: mazo at iitp.ru Estimated Hours: 0.0 Created an attachment (id=806) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=806) waf traceback Steps to reproduce: 0) Take a clean working copy 1) ./waf configure -d debug 2) ./waf build 3) ./waf configure -d optimized 4) ./waf build Then waf dies with exception TypeError: argument of type 'int' is not iterable. The full traceback is in attachment. Mercurial revision is b920710704c9. The current workaround is to add "./waf distclean" after step 2). This bug really annoys me, as I have to switch frequently between debug/optimized/release builds. Also this bug is probably an upstream (waf) bug, but I think, it should be kept here as a tracker 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. From code at nsnam.ece.gatech.edu Thu Apr 1 10:38:58 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Thu, 1 Apr 2010 13:38:58 -0400 Subject: [Ns-bugs] [Bug 855] waf dies badly when switching from debug to optimized build or vice versa In-Reply-To: References: Message-ID: <20100401173858.AC7F218005E@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=855 Andrey Mazo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mazo at iitp.ru --- Comment #1 from Andrey Mazo 2010-04-01 13:38:58 EDT --- (In reply to comment #0) > Mercurial revision is b920710704c9. Looks like revision 93a684517ead is not affected. It seems, that changeset d6c026abfb3f (waf upgrade from 1.5.11 to 1.5.13) broke the things. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Fri Apr 2 01:20:25 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Fri, 2 Apr 2010 04:20:25 -0400 Subject: [Ns-bugs] [Bug 855] waf dies badly when switching from debug to optimized build or vice versa In-Reply-To: References: Message-ID: <20100402082025.22DC45E41BA@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=855 --- Comment #2 from Andrey Mazo 2010-04-02 04:20:24 EDT --- (In reply to comment #1) Looks like, the bug is fixed with upstream changeset 7524 [1]. So it must be working in coming waf-1.5.16. [1] http://code.google.com/p/waf/source/detail?spec=svn7540&r=7524 -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Fri Apr 2 10:12:33 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Fri, 2 Apr 2010 13:12:33 -0400 Subject: [Ns-bugs] [Bug 671] RecvIfIndex tag in sockets In-Reply-To: References: Message-ID: <20100402171233.71F582DEB2E@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=671 --- Comment #10 from tazaki at sfc.wide.ad.jp 2010-04-02 13:12:32 EDT --- (In reply to comment #9) > > and not just the arriving interface index, and that we might want to just make > > this tag an IP_PKTINFO tag with multiple fields. What do you think-- > > Uh, this tag IP_PKTINFO with multiple fields sound good. > > > will we > > end up needing to fully support the ancillary data fields for ns-3-simu? > > Should they be handled in one or multiple tags? > > I hope these value can be supported. I've requested the review for patch of this feature. http://codereview.appspot.com/849047/show Please find the changeset. -- 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. From code at nsnam.ece.gatech.edu Sat Apr 3 15:42:22 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Sat, 3 Apr 2010 18:42:22 -0400 Subject: [Ns-bugs] [Bug 856] New: DropTailQueue: uninitialized variable Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=856 Summary: DropTailQueue: uninitialized variable Product: ns-3 Version: ns-3.7 Platform: All OS/Version: All Status: NEW Keywords: bug Severity: normal Priority: P5 Component: node module AssignedTo: ns-bugs at isi.edu ReportedBy: dimashink at gmail.com Estimated Hours: 0.0 Variable m_bytesInQueue should be initialized. Sometimes it is impossible to add packet in queue because the variable initially is not equal to zero and method Enqueue fails wen the mode is set to 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. From code at nsnam.ece.gatech.edu Sun Apr 4 07:00:50 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Sun, 4 Apr 2010 10:00:50 -0400 Subject: [Ns-bugs] [Bug 857] New: Link-Local Multicast handle in Ipv4 Output processing Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=857 Summary: Link-Local Multicast handle in Ipv4 Output processing 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: tazaki at sfc.wide.ad.jp CC: tazaki at sfc.wide.ad.jp Estimated Hours: 0.0 For example, when OSPF is used in ns-3, Hello packet is desalinized to 224.0.0.5, which is never forwarded by router. However, current internet-stack (ipv4-l3-proctocol, and ipv4-static-routing) requires routing table entry to send such packet. I think that the packet to 224.0.0.0/24 (link-local address) can be transmitted if output interface is specified. Attached patch tries to fix this 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. From code at nsnam.ece.gatech.edu Sun Apr 4 07:15:17 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Sun, 4 Apr 2010 10:15:17 -0400 Subject: [Ns-bugs] [Bug 858] New: support MSG_PEEK in IPv4/IPv6 raw socket Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=858 Summary: support MSG_PEEK in IPv4/IPv6 raw socket Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: tazaki at sfc.wide.ad.jp Estimated Hours: 0.0 MSG_PEEK is used during receiving the packet without removing the data from the queue. Attached patch aims to support this function in ipv4/ipv6 raw socket. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Sun Apr 4 07:31:38 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Sun, 4 Apr 2010 10:31:38 -0400 Subject: [Ns-bugs] [Bug 859] New: Output interface estimation for the source address bound socket in IPv4 Raw socket Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 Summary: Output interface estimation for the source address bound socket in IPv4 Raw socket 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: tazaki at sfc.wide.ad.jp Estimated Hours: 0.0 If the source address is specified, and output device is not specified, *AND* the destination address is 255.255.255.255 or multicast address, output device can be the device that owns specfied source address (at lease, in Linux 2.6.31 is like that). Attached patch will do this behavior. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Mon Apr 5 02:51:13 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 05:51:13 -0400 Subject: [Ns-bugs] [Bug 860] New: waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 Summary: waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: minor Priority: P4 Component: build system AssignedTo: ns-bugs at isi.edu ReportedBy: mazo at iitp.ru Estimated Hours: 0.0 The reason for this is that several headers are listed several times as source for some ns3header. For example, in "src/devices/wifi/wscript" (as of revision b920710704c9): 65 headers = bld.new_task_gen('ns3header') 66 headers.module = 'wifi' 67 headers.source = [ ... 75 'yans-wifi-channel.h', 76 'wifi-phy.h', <-- first ... 92 'nqap-wifi-mac.h', 93 'wifi-phy.h', <-- second ... 118 ] Waf tries to copy a new ns3header in one thread, while another thread already copied it and marked as read-only. In ns-3-dev there are a few such cases, so buildbot doesn't detect such failures. Example waf traceback: Build failed Traceback (most recent call last): File "/home/me/ns3nonfree/.waf-1.5.13-4340ef810f7db5d61c618fdf96cb5695/wafadmin/Runner.py", line 42, in loop else:ret=tsk.call_run() File "/home/me/ns3nonfree/.waf-1.5.13-4340ef810f7db5d61c618fdf96cb5695/wafadmin/Task.py", line 258, in call_run return self.run() File "", line 177, in run File "/usr/lib64/python2.6/shutil.py", line 99, in copy2 copyfile(src, dst) File "/usr/lib64/python2.6/shutil.py", line 53, in copyfile fdst = open(dst, 'wb') IOError: [Errno 13] Permission denied: 'debug/ns3/ipv4-l3-protocol.h' There are at least 2 possible fixes: 1) remove all such duplicates from all wscripts 2) remove all such duplicates in ns3header_taskgen::apply() and in ns3moduleheader_taskgen::apply() functions I'd prefer 2), because it allows to legally do things like: headers.source = [ # required by module1 'header1.h', 'header2.h', # required by module2 'header2.h', 'header3.h', ] to better keep track of dependencies and then unexport unused 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. From code at nsnam.ece.gatech.edu Mon Apr 5 03:05:21 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 06:05:21 -0400 Subject: [Ns-bugs] [Bug 860] waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs In-Reply-To: References: Message-ID: <20100405100522.0B2FC155B09@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 --- Comment #1 from Andrey Mazo 2010-04-05 06:05:21 EDT --- Created an attachment (id=807) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=807) proposed 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. From code at nsnam.ece.gatech.edu Mon Apr 5 03:32:13 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 06:32:13 -0400 Subject: [Ns-bugs] [Bug 847] Segfaults on BaseStationNetDevice with OnOffApplication and rtPS sched In-Reply-To: References: Message-ID: <20100405103213.6E351480119@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=847 Mohamed Amine ISMAIL 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. From code at nsnam.ece.gatech.edu Mon Apr 5 04:22:30 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 07:22:30 -0400 Subject: [Ns-bugs] [Bug 854] Support DROP_QUEUE reason-code in Ipv4FlowProbe In-Reply-To: References: Message-ID: <20100405112230.22032480070@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=854 --- Comment #2 from Gustavo J. A. M. Carneiro 2010-04-05 07:22:29 EDT --- (In reply to comment #1) > Created an attachment (id=805) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=805) [details] > Support DROP_QUEUE reason-code in Ipv4FlowProbe You should rename ns3::FlowProbeTag to ns3::Ipv4FlowProbeTag. There's an #include , which I am not sure if it is needed... In, Ipv4FlowProbe::QueueDropLogger, if the tag is not found maybe it should abort with 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. From code at nsnam.ece.gatech.edu Mon Apr 5 10:15:19 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 13:15:19 -0400 Subject: [Ns-bugs] [Bug 860] waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs In-Reply-To: References: Message-ID: <20100405171519.924D65E40B5@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 Gustavo J. A. M. Carneiro changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjcarneiro at gmail.com --- Comment #2 from Gustavo J. A. M. Carneiro 2010-04-05 13:15:19 EDT --- (In reply to comment #1) > Created an attachment (id=807) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=807) [details] > proposed fix I am fine with the proposed change, but I think you could use the builtin (python 2.4+) set type for a simpler fix. E.g.: - for filename in self.to_list(self.source): + for filename in set(self.to_list(self.source)): I don't think at this point we really need Python 2.3 compatibility. If we did, we'd just need to add this to the wscript: try: set except NameError: from sets import Set as set # Python 2.3 fallback -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Mon Apr 5 11:03:19 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 14:03:19 -0400 Subject: [Ns-bugs] [Bug 860] waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs In-Reply-To: References: Message-ID: <20100405180319.C834818033A@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 Andrey Mazo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mazo at iitp.ru --- Comment #3 from Andrey Mazo 2010-04-05 14:03:19 EDT --- (In reply to comment #2) > I am fine with the proposed change, but I think you could use the builtin > (python 2.4+) set type for a simpler fix. E.g.: > > - for filename in self.to_list(self.source): > + for filename in set(self.to_list(self.source)): > > I don't think at this point we really need Python 2.3 compatibility. If we > did, we'd just need to add this to the wscript: > > try: > set > except NameError: > from sets import Set as set # Python 2.3 fallback Thank you for a quick reply! I agree with your simpler fix: it's looks clearer. I've never thought about python-2.3 compatibility. But waf states, that it is compatible with it, so we'd better keep the compatibility too. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Mon Apr 5 11:04:14 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 14:04:14 -0400 Subject: [Ns-bugs] [Bug 860] waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs In-Reply-To: References: Message-ID: <20100405180414.9DD54155B39@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 Andrey Mazo changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #807 is|0 |1 obsolete| | --- Comment #4 from Andrey Mazo 2010-04-05 14:04:14 EDT --- Created an attachment (id=808) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=808) proposed fix based on sets -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Mon Apr 5 13:46:50 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Mon, 5 Apr 2010 16:46:50 -0400 Subject: [Ns-bugs] [Bug 860] waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs In-Reply-To: References: Message-ID: <20100405204650.6436620C0B1@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 --- Comment #5 from Gustavo J. A. M. Carneiro 2010-04-05 16:46:50 EDT --- (In reply to comment #4) > Created an attachment (id=808) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=808) [details] > proposed fix based on sets Looks good. Can you 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. From code at nsnam.ece.gatech.edu Mon Apr 5 21:23:50 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 00:23:50 -0400 Subject: [Ns-bugs] [Bug 861] New: add drop trace for condition when Ipv4RoutingProtocol::RouteInput() is false Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=861 Summary: add drop trace for condition when Ipv4RoutingProtocol::RouteInput() is false Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: ASSIGNED Severity: normal Priority: P5 Component: internet-stack AssignedTo: tomh at tomh.org ReportedBy: tomh at tomh.org CC: ns-bugs at isi.edu Estimated Hours: 0.0 Suggested on ns-developers mailing list here: http://mailman.isi.edu/pipermail/ns-developers/2010-April/007766.html Here is an untested patch. diff -r b920710704c9 src/internet-stack/ipv4-l3-protocol.cc --- a/src/internet-stack/ipv4-l3-protocol.cc Tue Mar 30 12:55:14 2010 -0400 +++ b/src/internet-stack/ipv4-l3-protocol.cc Mon Apr 05 21:20:32 2010 -0700 @@ -484,12 +484,17 @@ Ipv4L3Protocol::Receive( Ptr } NS_ASSERT_MSG (m_routingProtocol != 0, "Need a routing protocol object to process packets"); - m_routingProtocol->RouteInput (packet, ipHeader, device, + if (! m_routingProtocol->RouteInput (packet, ipHeader, device, MakeCallback (&Ipv4L3Protocol::IpForward, this), MakeCallback (&Ipv4L3Protocol::IpMulticastForward, this), MakeCallback (&Ipv4L3Protocol::LocalDeliver, this), MakeCallback (&Ipv4L3Protocol::RouteInputError, this) - ); + )) + { + NS_LOG_WARN ("No route found for forwarding packet. Drop."); + m_dropTrace (ipHeader, packet, DROP_NO_ROUTE, m_node->GetObject (), interface); + } + } -- 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. From code at nsnam.ece.gatech.edu Mon Apr 5 22:56:40 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 01:56:40 -0400 Subject: [Ns-bugs] [Bug 861] add drop trace for condition when Ipv4RoutingProtocol::RouteInput() is false In-Reply-To: References: Message-ID: <20100406055640.8E07B2DDBD9@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=861 --- Comment #1 from Tom Henderson 2010-04-06 01:56:40 EDT --- (In reply to comment #0) > Suggested on ns-developers mailing list here: > http://mailman.isi.edu/pipermail/ns-developers/2010-April/007766.html well, this is not really what the user was asking for, but still may be worth adding something like this since we have similar drop traces for route failures in outbound direction. -- 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. From code at nsnam.ece.gatech.edu Tue Apr 6 00:39:33 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 03:39:33 -0400 Subject: [Ns-bugs] [Bug 860] waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs In-Reply-To: References: Message-ID: <20100406073933.E167F2DDB50@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=860 Andrey Mazo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Andrey Mazo 2010-04-06 03:39:33 EDT --- (In reply to comment #5) > (In reply to comment #4) > > Created an attachment (id=808) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=808) [details] [details] > > proposed fix based on sets > > Looks good. Can you commit? Ok. Yes, I can. According to release schedule, ns-3-dev is open for such commits, so changeset c737d0a0e9a0. -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Tue Apr 6 01:45:17 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 04:45:17 -0400 Subject: [Ns-bugs] [Bug 862] New: NotifyInterfaceUp() Adds network route even when netmask is /32 Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=862 Summary: NotifyInterfaceUp() Adds network route even when netmask is /32 Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: routing AssignedTo: ns-bugs at isi.edu ReportedBy: zarhan at cc.hut.fi Estimated Hours: 0.0 When configuring an interface with netmask of /32, (using with VirtualNetDevice and tunnels), and Ptr->Setup(i) is called, this, in turn calls NotifyInterfaceUp() of all routing protocols. In e.g. void Ipv4StaticRouting::NotifyInterfaceUp (uint32_t i) { NS_LOG_FUNCTION (this << i); // If interface address and network mask have been set, add a route // to the network of the interface (like e.g. ifconfig does on a // Linux box) for (uint32_t j = 0; j < m_ipv4->GetNAddresses (i); j++) { if (m_ipv4->GetAddress (i,j).GetLocal () != Ipv4Address () && m_ipv4->GetAddress (i,j).GetMask () != Ipv4Mask ()) { AddNetworkRouteTo (m_ipv4->GetAddress (i,j).GetLocal ().CombineMask (m _ipv4->GetAddress (i,j).GetMask ()), m_ipv4->GetAddress (i,j).GetMask (), i); } } } the network is added even when the mask is /32. This leads to same entry being in routing table twice (both the if-addr and as "network", even if the "network" size is /32!). Even in Linux, if you add an ip address with mask of 255.255.255.255, nothing gets added to routing table. Proposed line to add: if (m_ipv4->GetAddress (i,j).GetMask()==Ipv4Mask::GetOnes()) { return; } However, not submitting a patch yet - should this be added to ALL routing protocols, or perhaps just list-routing? In Linux (just a quick test with my wireless interface that I'm not using right now, also omitting lines pertaining to my wired Internet connection). # ifconfig wlan up # ifconfig wlan 4.4.4.4 netmask 255.255.255.255 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo # ifconfig wlan 4.4.4.4 netmask 255.255.255.0 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 4.4.4.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Tue Apr 6 01:59:45 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 04:59:45 -0400 Subject: [Ns-bugs] [Bug 862] NotifyInterfaceUp() Adds network route even when netmask is /32 In-Reply-To: References: Message-ID: <20100406085945.B6A6A48013F@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=862 --- Comment #1 from Antti M?kel? 2010-04-06 04:59:45 EDT --- Created an attachment (id=809) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=809) Patch to fix the issue in static routing Well, here's an example how I fixed it with ipv4-static-routing.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. From code at nsnam.ece.gatech.edu Tue Apr 6 05:43:22 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 08:43:22 -0400 Subject: [Ns-bugs] [Bug 862] NotifyInterfaceUp() Adds network route even when netmask is /32 In-Reply-To: References: Message-ID: <20100406124322.A251B20C10B@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=862 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomh at tomh.org --- Comment #2 from Tom Henderson 2010-04-06 08:43:22 EDT --- > > However, not submitting a patch yet - should this be added to ALL routing > protocols, or perhaps just list-routing? I agree with the patch. I believe that only Ipv4StaticRouting implements this type of behavior, since it is the only object that holds static or connected routes, so I would suggest that with our routing framework, it should just go to Ipv4StaticRouting. If another standalone (i.e. for use outside of list routing context) routing protocol wants to provide connected routes, it should also implement it. I think that only AODV right now is designed with this use in mind, and in that case, you probably don't want the connected routes 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. From code at nsnam.ece.gatech.edu Tue Apr 6 11:57:48 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 14:57:48 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100406185748.35CD320C10B@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #5 from Tom Henderson 2010-04-06 14:57:47 EDT --- I'd like to try to resolve this for the current release. To summarize, NetDevice::Mtu presently has two problems. 1) it leads to order-of-initialization problems since it is linked to subclass attributes like Csma FrameSize. 2) the default value doesn't get stored properly in the config store system (bug 845). Here are the options I see: 1) simply remove this attribute, since each subclass has its own way of configuring frame size via attributes pro: simple (attribute was broken anyway) con: we lose this commonality among devices, especially user familiarity with the concept (ifconfig mtu ...). If I do an "ifconfig mtu N" from a container bound to an ns-3 NetDevice, I will need to downcast the pointer and search for the right attribute (unless we preserve base class SetMtu/GetMtu methods). 2) move this attribute to each subclass, but remove the device-specific frame size attributes so that we don't have two attributes pointing to one member variable (again leading to initialization order problems and user confusion) pro: MTU can be device specific (more realistic) con: breaks ns-3 API 3) move Mtu attribute to each subclass, and decouple this attribute from the frame size attribute; these are two separate member variables. This means that a user could e.g. set an Ethernet MTU of 1000 bytes even though the frame size was set to 1518 bytes. Consistency checking would still be needed (that MTU <= (frame size - header size), for instance). pro: preserves a device-specific MTU and preserves ns-3 API con: still needs to be robust to initialization order issues; need to document to users that these concepts (FrameSize and Mtu) are still related in some way, but are not locked in-step to each other Preferences, comments? -- 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. From code at nsnam.ece.gatech.edu Tue Apr 6 12:00:28 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 15:00:28 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100406190028.9870A5E41BE@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #6 from Tom Henderson 2010-04-06 15:00:28 EDT --- (In reply to comment #5) 2) the default value doesn't get stored properly in the config > store system (bug 845). I'd like to add that this bug 845 issue seems orthogonal to the real issue which is that Mtu and FrameSize, by being bound to the same underlying variable, have order of initialization issues that can cause errors by users not realizing that a value of one attribute has been overridden by another. -- 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. From code at nsnam.ece.gatech.edu Tue Apr 6 13:02:50 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Tue, 6 Apr 2010 16:02:50 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100406200250.F12F52DC1E1@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #7 from Craig Dowell 2010-04-06 16:02:50 EDT --- The original idea was that both mtu and frame size were device-related things and if someone wanted to set frame size, we would do that and then make sure mtu was consistent. If someone wanted to set mtu, we would do that and then make sure frame size was consistent -- leading to a simple, one-step process to, for example, enable jumbo datagrams. Conceptually, mtu and frame size are indirectly describing the same quantity -- the number of bits that can be sent across a channel. There are also encapsulation modes (Dix, Llc) to consider which also get into the picture, so there are really three inter-related quantities. Trying to make this work for two classes of users who thought differently about which was the more "important" attribute, mtu or frame size, has gotten a bit out of hand and resulted in quite subtle problems. Keeping in mind our guidance that when in doubt we should do it like Linux, I think the best answer here is to simply treat framesize as a maximum value, like in a linux device: #define MAX_ETH_FRAME_SIZE 1536 We would then decouple mtu and frame size and to runtime checks to make sure that the asked-for MTU fits into the maximum frame size. If someone wants to actually crank up the frame size to 9000 bytes, they could by setting the framesize attribute and also the mtu attribute (in that order). This is an order-dependent two-step process (which was what I originally wanted to avoid). However, it turns out that I did not actually avoid dependency issues but in fact created subtler ones. So I favor Tom's option 3: 3) move Mtu attribute to each subclass, and decouple this attribute from the frame size attribute; these are two separate member variables. This means that a user could e.g. set an Ethernet MTU of 1000 bytes even though the frame size was set to 1518 bytes. Consistency checking would still be needed (that MTU <= (frame size - header size), for instance). Frame size then means "maximum frame size." -- 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. From code at nsnam.ece.gatech.edu Tue Apr 6 23:39:47 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 02:39:47 -0400 Subject: [Ns-bugs] [Bug 863] New: Wrong Scalar arithmetics Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=863 Summary: Wrong Scalar arithmetics Product: ns-3 Version: ns-3-dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: simulation core AssignedTo: ns-bugs at isi.edu ReportedBy: boyko at iitp.ru Estimated Hours: 0.0 Test program: #include #include "ns3/simulator-module.h" int main () { std::cout << (ns3::Scalar (0.9) / ns3::Scalar (1.0)).GetDouble () << "\n"; return 0; } Expected output: 0.9 Actual output (ns-3-dev changeset: 6103:12931126ea21) : -0.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. From code at nsnam.ece.gatech.edu Tue Apr 6 23:52:23 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 02:52:23 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407065223.F29B75E4075@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #8 from Mathieu Lacage 2010-04-07 02:52:23 EDT --- (In reply to comment #5) > 2) move this attribute to each subclass, but remove the device-specific frame > size attributes so that we don't have two attributes pointing to one member > variable (again leading to initialization order problems and user confusion) > pro: MTU can be device specific (more realistic) > con: breaks ns-3 API > > 3) move Mtu attribute to each subclass, and decouple this attribute from the > frame size attribute; these are two separate member variables. This means that > a user could e.g. set an Ethernet MTU of 1000 bytes even though the frame size > was set to 1518 bytes. Consistency checking would still be needed (that MTU <= > (frame size - header size), for instance). > pro: preserves a device-specific MTU and preserves ns-3 API > con: still needs to be robust to initialization order issues; need to > document to users that these concepts (FrameSize and Mtu) are still related in > some way, but are not locked in-step to each other The only robust way of doing this is 2). 3) is not workable because it introduces dependencies between attributes. i.e., the result of a Set call will depend on a earlier Set call. If each attribute is not independent from all other attributes, this breaks many assumptions which in turn breaks code attempting to perform generic serialization/deserialization of attributes. For example ConfigStore will break in very subtle ways if we go with 3). -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 01:26:04 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 04:26:04 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407082604.8449F20C0DD@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #9 from Mathieu Lacage 2010-04-07 04:26:04 EDT --- Created an attachment (id=810) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=810) implement option 2. All tests pass with this patch. A couple of interesting notes: 1) this removes all the frame size code to avoid confusion between the frame size and mtu 2) this fixes a bug in udp-client-server-test.cc: it was setting the device mtu but this did not work correctly so, the test was working when it should not. 3) I have been really super careful to keep the existing default behavior so that existing code which did not change the mtu would keep working. 4) I have tried really hard to not introduce new indentation in all files I touched: a lot of them do not have coding-style indentation so, I had to do it by hand so, I might have gotten it wrong. 5) Requires a python rescan on top. Did not include it in this patch to avoid confusion. I really would like to fix this bug for this release so, it would be helpful if someone could review it. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 04:39:23 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 07:39:23 -0400 Subject: [Ns-bugs] [Bug 845] Config::SetDefault not being reported correctly in ConfigStore output In-Reply-To: References: Message-ID: <20100407113923.B562C20C0B1@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=845 --- Comment #1 from Mathieu Lacage 2010-04-07 07:39:23 EDT --- the problem here is that this is a bug in src/core/ -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 07:36:36 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:36:36 -0400 Subject: [Ns-bugs] [Bug 864] New: invalid return value in UdpSocketImpl and Ipv4RawSocketImpl Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=864 Summary: invalid return value in UdpSocketImpl and Ipv4RawSocketImpl Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr Estimated Hours: 0.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. From code at nsnam.ece.gatech.edu Wed Apr 7 07:38:43 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:38:43 -0400 Subject: [Ns-bugs] [Bug 864] invalid return value in UdpSocketImpl::Send and Ipv4RawSocketImpl::Send In-Reply-To: References: Message-ID: <20100407143844.04B5620C066@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=864 Mathieu Lacage changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|invalid return value in |invalid return value in |UdpSocketImpl and |UdpSocketImpl::Send and |Ipv4RawSocketImpl |Ipv4RawSocketImpl::Send --- Comment #1 from Mathieu Lacage 2010-04-07 10:38:43 EDT --- originally, reported by Hajime Tazaki -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:40:53 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:40:53 -0400 Subject: [Ns-bugs] [Bug 865] New: Ipv4RawSocketImpl::RecvFrom does not return from address all the time. Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=865 Summary: Ipv4RawSocketImpl::RecvFrom does not return from address all the time. Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: internet-stack AssignedTo: ns-bugs at isi.edu ReportedBy: mathieu.lacage at sophia.inria.fr Estimated Hours: 0.0 reported by Hajime Tazaki -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:41:08 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:41:08 -0400 Subject: [Ns-bugs] [Bug 857] Link-Local Multicast handle in Ipv4 Output processing In-Reply-To: References: Message-ID: <20100407144108.CDB3B20C116@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=857 --- Comment #1 from tazaki at sfc.wide.ad.jp 2010-04-07 10:41:08 EDT --- Created an attachment (id=811) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=811) Handle IPv4 Link-local multicast address correctly -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:41:55 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:41:55 -0400 Subject: [Ns-bugs] [Bug 858] support MSG_PEEK in IPv4/IPv6 raw socket In-Reply-To: References: Message-ID: <20100407144155.11C945E407C@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=858 --- Comment #1 from tazaki at sfc.wide.ad.jp 2010-04-07 10:41:54 EDT --- Created an attachment (id=812) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=812) Support MSG_PEEK flag in socket -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:42:05 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:42:05 -0400 Subject: [Ns-bugs] [Bug 865] Ipv4RawSocketImpl::RecvFrom does not return from address all the time. In-Reply-To: References: Message-ID: <20100407144206.5306B20C066@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=865 --- Comment #1 from Mathieu Lacage 2010-04-07 10:42:05 EDT --- Created an attachment (id=813) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=813) patch from hajime see also http://codereview.appspot.com/805044/show -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:42:56 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:42:56 -0400 Subject: [Ns-bugs] [Bug 859] Output interface estimation for the source address bound socket in IPv4 Raw socket In-Reply-To: References: Message-ID: <20100407144256.CF4AA18033A@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 --- Comment #1 from tazaki at sfc.wide.ad.jp 2010-04-07 10:42:56 EDT --- Created an attachment (id=814) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=814) Picking output interface from source address -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:45:51 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:45:51 -0400 Subject: [Ns-bugs] [Bug 864] invalid return value in UdpSocketImpl::Send and Ipv4RawSocketImpl::Send In-Reply-To: References: Message-ID: <20100407144552.055A24800EA@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=864 --- Comment #2 from Mathieu Lacage 2010-04-07 10:45:51 EDT --- Created an attachment (id=815) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=815) patch from hajime see also http://codereview.appspot.com/805044/show -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:50:07 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:50:07 -0400 Subject: [Ns-bugs] [Bug 865] Ipv4RawSocketImpl::RecvFrom does not return from address all the time. In-Reply-To: References: Message-ID: <20100407145008.0669E1550BF@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=865 Mathieu Lacage changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |VERIFIED Resolution| |FIXED --- Comment #2 from Mathieu Lacage 2010-04-07 10:50:07 EDT --- changeset bef40786d55b -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 07:49:50 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 10:49:50 -0400 Subject: [Ns-bugs] [Bug 864] invalid return value in UdpSocketImpl::Send and Ipv4RawSocketImpl::Send In-Reply-To: References: Message-ID: <20100407144951.90D90183577@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=864 Mathieu Lacage changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Mathieu Lacage 2010-04-07 10:49:50 EDT --- changeset 21c9ea05058b -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 08:11:50 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 11:11:50 -0400 Subject: [Ns-bugs] [Bug 859] Output interface estimation for the source address bound socket in IPv4 Raw socket In-Reply-To: References: Message-ID: <20100407151150.9A47F155A56@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomh at tomh.org --- Comment #2 from Tom Henderson 2010-04-07 11:11:50 EDT --- +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. From code at nsnam.ece.gatech.edu Wed Apr 7 08:13:13 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 11:13:13 -0400 Subject: [Ns-bugs] [Bug 863] Wrong Scalar arithmetics In-Reply-To: References: Message-ID: <20100407151313.842812DDA32@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=863 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2 CC| |ns-bugs at isi.edu, | |tomh at tomh.org AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria | |.fr Severity|normal |critical -- 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. You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 08:15:34 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 11:15:34 -0400 Subject: [Ns-bugs] [Bug 862] NotifyInterfaceUp() Adds network route even when netmask is /32 In-Reply-To: References: Message-ID: <20100407151534.99E4F5E418A@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=862 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 |P3 CC| |ns-bugs at isi.edu AssignedTo|ns-bugs at isi.edu |tomh at tomh.org --- Comment #3 from Tom Henderson 2010-04-07 11:15:33 EDT --- I plan to push this during the current maintenance window if there are no other comments. -- 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. You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 08:55:01 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 11:55:01 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407155501.CB84E20C0A4@deliverator6.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #10 from Tom Henderson 2010-04-07 11:55:01 EDT --- (In reply to comment #9) > Created an attachment (id=810) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=810) [details] > implement option 2. > > All tests pass with this patch. A couple of interesting notes: > > 1) this removes all the frame size code to avoid confusion between the frame > size and mtu > 2) this fixes a bug in udp-client-server-test.cc: it was setting the device mtu > but this did not work correctly so, the test was working when it should not. > 3) I have been really super careful to keep the existing default behavior so > that existing code which did not change the mtu would keep working. > 4) I have tried really hard to not introduce new indentation in all files I > touched: a lot of them do not have coding-style indentation so, I had to do it > by hand so, I might have gotten it wrong. > 5) Requires a python rescan on top. Did not include it in this patch to avoid > confusion. > > I really would like to fix this bug for this release so, it would be helpful if > someone could review it. I am fine with this solution in general and the approach of this patch; I assume you preserve the methods SetMtu/GetMtu for backward compatibility. I disagree with a few of the defaults; suggest that they be changed as follows: Bridge: 1500 CSMA: 1500 Emu: ? /* Should we delete Mtu attribute here? */ TapBridge: ? /* Should we delete Mtu attribute here? */ Virtual: 1500 WiMAX: 1400 /* Amine should confirm this value */ I am OK with not enforcing a frame size on Csma because users may want to turn Mtu to 9000 (Jumbograms) and it would be nice if they could do so without rebuilding the csma code. Regarding wifi, how do you propose to handle MSDU aggregation? A user may think that he/she can set the MTU on an 802.11n device to larger and will be blocked by the integer constant set to 2304. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 09:03:30 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 12:03:30 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407160330.E15AC2DDCE4@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 Mathieu Lacage changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amine.ismail at sophia.inria.f | |r, nbaldo at cttc.es --- Comment #11 from Mathieu Lacage 2010-04-07 12:03:29 EDT --- (In reply to comment #10) > > I am fine with this solution in general and the approach of this patch; I > assume you preserve the methods SetMtu/GetMtu for backward compatibility. I think that it makes sense to keep these methods around, for linux net_device alignment. > I disagree with a few of the defaults; suggest that they be changed as follows: I don't care much about the defaults: I merely copied what was in there already. I would support keeping the emu/tapbridge mtus but it's not something I care much about. > Bridge: 1500 > CSMA: 1500 > Emu: ? /* Should we delete Mtu attribute here? */ > TapBridge: ? /* Should we delete Mtu attribute here? */ > Virtual: 1500 > WiMAX: 1400 /* Amine should confirm this value */ I have CCed amine. > > I am OK with not enforcing a frame size on Csma because users may want to turn > Mtu to 9000 (Jumbograms) and it would be nice if they could do so without > rebuilding the csma code. > > Regarding wifi, how do you propose to handle MSDU aggregation? A user may > think that he/she can set the MTU on an 802.11n device to larger and will be > blocked by the integer constant set to 2304. I think that if users think this, they are seriously misleaded. i.e., this is not what MSDU aggregation is about but I guess that is a question for our new wifi maintainer. CCing him. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 09:37:02 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 12:37:02 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407163702.C72E815407B@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #12 from Mohamed Amine ISMAIL 2010-04-07 12:37:02 EDT --- default MTU for WiMAX: ====================== The 802.16 standard allows about 2039 bytes of payload (the len is coded on 11bits including the size of the header=6 and optional 2bytes crc). 16ng-ipv4-over-802-dot-16-ipcs IETF draft specifies that the default MTU should be 1500. However The WiMAX forum recommended 1400 bytes!:) I think that it is wise to use the value recommended by the WiMAx forum (1400) -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 09:40:01 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 12:40:01 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407164001.273145E40E8@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #13 from Tom Henderson 2010-04-07 12:40:00 EDT --- (In reply to comment #11) > > Regarding wifi, how do you propose to handle MSDU aggregation? A user may > > think that he/she can set the MTU on an 802.11n device to larger and will be > > blocked by the integer constant set to 2304. > > I think that if users think this, they are seriously misleaded. i.e., this is > not what MSDU aggregation is about but I guess that is a question for our new > wifi maintainer. CCing him. I thought I had read in the past that 802.11n aggregation allowed larger MTUs, but I will defer to the experts here because I could have misunderstood it. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 09:42:55 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 12:42:55 -0400 Subject: [Ns-bugs] [Bug 831] Insufficient numerical precision of timestamped simulation time in the ascii trace file (ns-3.7) In-Reply-To: References: Message-ID: <20100407164255.9BAAF155B37@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=831 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ns-bugs at isi.edu 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 on the CC list for the bug. You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 09:43:15 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 12:43:15 -0400 Subject: [Ns-bugs] [Bug 830] Insufficient numerical precision of timestamped simulation time in the ascii trace file (ns-3-dev) In-Reply-To: References: Message-ID: <20100407164315.633E7183569@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=830 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ns-bugs at isi.edu 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 on the CC list for the bug. You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 09:48:31 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 12:48:31 -0400 Subject: [Ns-bugs] [Bug 857] Link-Local Multicast handle in Ipv4 Output processing In-Reply-To: References: Message-ID: <20100407164831.8B2A3155B97@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=857 Tom Henderson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomh at tomh.org --- Comment #2 from Tom Henderson 2010-04-07 12:48:31 EDT --- +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. From code at nsnam.ece.gatech.edu Wed Apr 7 11:17:35 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 14:17:35 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407181735.D81221834AC@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #14 from Craig Dowell 2010-04-07 14:17:34 EDT --- Okay, I hadn't considered automatic attribute setter programs which can decide on their own setter execution order. As you suggest, if there are any inter-attribute dependencies that can produce errors, these can fail in unexpected ways as the setters are called according to the convenience of the program, not the semantics of the attributes. The corollary is that *any* consistency checks for attributes *must* be done after Simulator::Run() is called and not during configuration time. This should be advertized somewhere fairly prominently. I think that demanding that attributes be completely independent at *all* times is too restrictive. It seems clear to me that attributes can have dependencies, though, so consistency checking at run-time seems appropriate. With that in mind, having an mtu and a maximum frame size attribute (like in Linux) is still possible -- the consistency checks just need to be done while the device is running. I still think having a maximum frame size is important because of the following: Regarding the proposed patch, be aware that if you set the mtu to the default 1500 bytes and select LLC/SNAP framing you are going to be capable of generating illegally long Ethernet packets! MTU 1500, DIX encapsulation works out to 1518 byte frames. MTU 1492, LLC/SNAP encapsulation works out to 1518 byte frames. MTU 1500, LLC/SNAP encapsulation works out to 1526 byte frames. This is why the frame size was there in the first place; and the mtu from framesize calculation was there so a user didn't have to get out a calculator to set mtu properly. The fact that this behavior can happen so easily should also be advertized somewhere prominently if maximum frame size is removed. Would most people consider it a bug? It's a small error, but it is a modelling error if you think CSMA is Ethernet with respect to framing. Having a maximum frame size attribute that derfaults to 1518 bytes would at least cause a runtime error if a user neglects to reduce MTU to 1492 when setting Llc encapsulation. Of course, CSMA is not Ethernet, and it could be argued that the maximum frame size in a CSMA device is coincidentally 1526 bytes not 1518 and we just don't use those extra eight bytes in the default case :-) That said, it's obvious that having a maximum frame size attribute is not very popular, so I'll defer to the majority on this one. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 11:45:49 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 14:45:49 -0400 Subject: [Ns-bugs] [Bug 831] Insufficient numerical precision of timestamped simulation time in the ascii trace file (ns-3.7) In-Reply-To: References: Message-ID: <20100407184549.59E222DEE03@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=831 --- Comment #1 from Craig Dowell 2010-04-07 14:45:49 EDT --- With the new tracing framework, a user can set the floating point precision of the underlying stream to whatever is required. AsciiTraceHelper helper; Ptr stream = helper.CreateFileStream ("file"); stream->GetStream ()->precision (8); Does that meet your needs? -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 11:53:17 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 14:53:17 -0400 Subject: [Ns-bugs] [Bug 830] Insufficient numerical precision of timestamped simulation time in the ascii trace file (ns-3-dev) In-Reply-To: References: Message-ID: <20100407185317.BA9DA480075@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=830 --- Comment #1 from Craig Dowell 2010-04-07 14:53:17 EDT --- With the new tracing framework, a user can set the floating point precision of the underlying stream to whatever is required. AsciiTraceHelper helper; Ptr stream = helper.CreateFileStream ("file"); stream->GetStream ()->precision (8); Does that meet your needs? -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 12:49:30 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 15:49:30 -0400 Subject: [Ns-bugs] [Bug 819] Build break when gtk not installed In-Reply-To: References: Message-ID: <20100407194930.6304639C42A@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=819 Josh Pelkey changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Josh Pelkey 2010-04-07 15:49:30 EDT --- (In reply to comment #2) > > There is code to detect gtk: > > The problem was, I think, that some of the code in contrib ignored that code. > I also think I saw a fix written by Mathieu fly by, but I'm not certain. I no > longer have a machine handy without GTK to test this. > > If it's fixed, I'm fine with whoever fixed it closing the bug. I think maybe you are referring to this changeset: http://code.nsnam.org/ns-3-dev/rev/93a684517ead I also just tested the build on a system without GTK. Went ok. Marking this resolved. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 13:10:46 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 16:10:46 -0400 Subject: [Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default In-Reply-To: References: Message-ID: <20100407201046.F2CA44800C2@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=822 --- Comment #15 from Tom Henderson 2010-04-07 16:10:46 EDT --- (In reply to comment #14) > > The corollary is that *any* consistency checks for attributes *must* be done > after Simulator::Run() is called and not during configuration time. This > should be advertized somewhere fairly prominently. I think that demanding that > attributes be completely independent at *all* times is too restrictive. It > seems clear to me that attributes can have dependencies, though, so consistency > checking at run-time seems appropriate. I agree with these observations: 1) document this prominently somewhere, 2) we cannot escape any dependencies between attributes in general so run-time checking is needed > > With that in mind, having an mtu and a maximum frame size attribute (like in > Linux) is still possible -- the consistency checks just need to be done while > the device is running. I still think having a maximum frame size is important > because of the following: > > Regarding the proposed patch, be aware that if you set the mtu to the default > 1500 bytes and select LLC/SNAP framing you are going to be capable of > generating illegally long Ethernet packets! > > MTU 1500, DIX encapsulation works out to 1518 byte frames. > MTU 1492, LLC/SNAP encapsulation works out to 1518 byte frames. > MTU 1500, LLC/SNAP encapsulation works out to 1526 byte frames. > > This is why the frame size was there in the first place; and the mtu from > framesize calculation was there so a user didn't have to get out a calculator > to set mtu properly. The fact that this behavior can happen so easily should > also be advertized somewhere prominently if maximum frame size is removed. > Would most people consider it a bug? > > It's a small error, but it is a modelling error if you think CSMA is Ethernet > with respect to framing. Having a maximum frame size attribute that derfaults > to 1518 bytes would at least cause a runtime error if a user neglects to reduce > MTU to 1492 when setting Llc encapsulation. Of course, CSMA is not Ethernet, > and it could be argued that the maximum frame size in a CSMA device is > coincidentally 1526 bytes not 1518 and we just don't use those extra eight > bytes in the default case :-) > > That said, it's obvious that having a maximum frame size attribute is not very > popular, so I'll defer to the majority on this one. I sympathize with the above; the main practical issue that I see in this specific case is that our abstract Csma device can represent, in practice, different varieties of Ethernet technology with different maximum frame sizes. If Csma was intended to model 10Base5 Ethernet specifically, then yes, I would argue we need to support the above restriction. But various Ethernet frame sizes can range up to 9000 bytes. I think a more common use case from a usability perspective is that if a user wants to simulate jumbo frames, he or she would prefer to just do: Config::SetDefault ("ns3::CsmaNetDevice::Mtu", UintegerValue ("9000")); rather than set both an Mtu and a FrameSize attribute, and we should just document some disclaimer like the following in csma-net-device.h: "The CsmaNetDevice does not model any particular Ethernet technology specifically, but Ethernet-like devices in general. Since real-world Ethernet can support different frame sizes depending on the technology, this device does not enforce a maximum MTU. It is possible to configure the MTU to a value that would not be supported by a particular underlying Ethernet technology." I would be OK with setting an integer constant upper bound on the frame size such as 9100 bytes (since there are practical limits to frame sizes even for jumbo-capable devices due to the error checking capabilities of the codes); this would prevent obvious user error of setting it accidentally to very high values. But I don't care strongly about this constant. -- 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. From code at nsnam.ece.gatech.edu Wed Apr 7 13:46:58 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 16:46:58 -0400 Subject: [Ns-bugs] [Bug 833] OnOffApplication with PacketSocket: sniffs all traffic In-Reply-To: References: Message-ID: <20100407204658.135F7183564@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=833 Josh Pelkey changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpelkey at gatech.edu --- Comment #4 from Josh Pelkey 2010-04-07 16:46:57 EDT --- (In reply to comment #2) > Created an attachment (id=782) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=782) [details] > patch > > I think this is the most elegant patch. Calls ShutDownSend and ShutDownRecv > where appropriate. No trace files change with the patch. What happens if OnOffApplication uses TCP sockets? It seems like this might not work. For example, after applying this patch and running examples/csma/csma-star.cc, the tcpdumps show a bunch of SYN ACKS coming in to node 0, over and over 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. From code at nsnam.ece.gatech.edu Wed Apr 7 14:42:14 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 17:42:14 -0400 Subject: [Ns-bugs] [Bug 833] OnOffApplication with PacketSocket: sniffs all traffic In-Reply-To: References: Message-ID: <20100407214214.96CEC2DDCDD@deliverator1.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=833 --- Comment #5 from Gustavo J. A. M. Carneiro 2010-04-07 17:42:14 EDT --- (In reply to comment #4) > (In reply to comment #2) > > Created an attachment (id=782) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=782) [details] [details] > > patch > > > > I think this is the most elegant patch. Calls ShutDownSend and ShutDownRecv > > where appropriate. No trace files change with the patch. > > What happens if OnOffApplication uses TCP sockets? It seems like this might > not work. For example, after applying this patch and running > examples/csma/csma-star.cc, the tcpdumps show a bunch of SYN ACKS coming in to > node 0, over and over again. Maybe it's a bug in TCP's implementation of ShutdownSend|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. From code at nsnam.ece.gatech.edu Wed Apr 7 16:41:16 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 19:41:16 -0400 Subject: [Ns-bugs] [Bug 859] Output interface estimation for the source address bound socket in IPv4 Raw socket In-Reply-To: References: Message-ID: <20100407234116.5784C1558F5@deliverator3.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 --- Comment #3 from tazaki at sfc.wide.ad.jp 2010-04-07 19:41:16 EDT --- (In reply to comment #2) > +1 Tom, thanks. In order to reflect this modification, I've added one test in udp-test.cc as follows, but it cause another problem. diff -r ddd5c567f02d src/internet-stack/udp-test.cc --- a/src/internet-stack/udp-test.cc Thu Apr 08 00:34:56 2010 +0900 +++ b/src/internet-stack/udp-test.cc Thu Apr 08 01:31:43 2010 +0900 @@ -239,6 +239,16 @@ m_receivedPacket->RemoveAllByteTags (); m_receivedPacket2->RemoveAllByteTags (); + // Simple Link-local multicast test + + txSocket->BindToNetDevice (txDev1); + SendData (txSocket, "224.0.0.9"); + NS_TEST_EXPECT_MSG_EQ (m_receivedPacket->GetSize (), 123, "trivial"); + NS_TEST_EXPECT_MSG_EQ (m_receivedPacket2->GetSize (), 0, "second socket should not receive it (it is bound specifically to the second interface's address"); + + m_receivedPacket->RemoveAllByteTags (); + m_receivedPacket2->RemoveAllByteTags (); + // Broadcast test with multiple receiving sockets // When receiving broadcast packets, all sockets sockets bound to During using raw socket, we never face this problem (since every packet goes up to the socket), but in UDP, we use routing table for local delivery (in Ipv4StaticRouting::RoutInput), but it seems not to working so far. bool Ipv4StaticRouting::RouteInput (Ptr p, const Ipv4Header &ipHeader, Ptr idev, UnicastForwardCallback ucb, MulticastForwardCallback mcb, LocalDeliverCallback lcb, ErrorCallback ecb) { // Multicast recognition; handle local delivery here // if (ipHeader.GetDestination ().IsMulticast ()) { NS_LOG_LOGIC ("Multicast destination"); Ptr mrtentry = LookupStatic(ipHeader.GetSource (), ipHeader.GetDestination (), m_ipv4->GetInterfaceForDevice (idev)); Do you have any idea ? I'll keep thinking how to solve 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. From code at nsnam.ece.gatech.edu Wed Apr 7 16:45:48 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 19:45:48 -0400 Subject: [Ns-bugs] [Bug 859] Output interface estimation for the source address bound socket in IPv4 Raw socket In-Reply-To: References: Message-ID: <20100407234548.B19AB18324A@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 --- Comment #4 from tazaki at sfc.wide.ad.jp 2010-04-07 19:45:48 EDT --- (In reply to comment #3) I'm sorry, but I had mistaken to reply message. Comment #3 is not reply for this bug. Please ignore it. > (In reply to comment #2) > > +1 > > Tom, thanks. > > In order to reflect this modification, I've added one test in udp-test.cc as > follows, but it cause another 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. From code at nsnam.ece.gatech.edu Wed Apr 7 16:48:28 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 19:48:28 -0400 Subject: [Ns-bugs] [Bug 857] Link-Local Multicast handle in Ipv4 Output processing In-Reply-To: References: Message-ID: <20100407234828.9895148012E@deliverator2.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=857 --- Comment #3 from tazaki at sfc.wide.ad.jp 2010-04-07 19:48:28 EDT --- (In reply to comment #2) > +1 Tom, thanks. #I repied this message as wrong bug number (#859), but this message is surely for this bug. In order to reflect this modification, I've added one test in udp-test.cc as follows, but it cause another problem. diff -r ddd5c567f02d src/internet-stack/udp-test.cc --- a/src/internet-stack/udp-test.cc Thu Apr 08 00:34:56 2010 +0900 +++ b/src/internet-stack/udp-test.cc Thu Apr 08 01:31:43 2010 +0900 @@ -239,6 +239,16 @@ m_receivedPacket->RemoveAllByteTags (); m_receivedPacket2->RemoveAllByteTags (); + // Simple Link-local multicast test + + txSocket->BindToNetDevice (txDev1); + SendData (txSocket, "224.0.0.9"); + NS_TEST_EXPECT_MSG_EQ (m_receivedPacket->GetSize (), 123, "trivial"); + NS_TEST_EXPECT_MSG_EQ (m_receivedPacket2->GetSize (), 0, "second socket should not receive it (it is bound specifically to the second interface's address"); + + m_receivedPacket->RemoveAllByteTags (); + m_receivedPacket2->RemoveAllByteTags (); + // Broadcast test with multiple receiving sockets // When receiving broadcast packets, all sockets sockets bound to During using raw socket, we never face this problem (since every packet goes up to the socket), but in UDP, we use routing table for local delivery (in Ipv4StaticRouting::RoutInput), but it seems not to working so far. bool Ipv4StaticRouting::RouteInput (Ptr p, const Ipv4Header &ipHeader, Ptr idev, UnicastForwardCallback ucb, MulticastForwardCallback mcb, LocalDeliverCallback lcb, ErrorCallback ecb) { // Multicast recognition; handle local delivery here // if (ipHeader.GetDestination ().IsMulticast ()) { NS_LOG_LOGIC ("Multicast destination"); Ptr mrtentry = LookupStatic(ipHeader.GetSource (), ipHeader.GetDestination (), m_ipv4->GetInterfaceForDevice (idev)); Do you have any idea ? I'll keep thinking how to solve 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. From code at nsnam.ece.gatech.edu Wed Apr 7 19:29:41 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 22:29:41 -0400 Subject: [Ns-bugs] [Bug 859] Output interface estimation for the source address bound socket in IPv4 Raw socket In-Reply-To: References: Message-ID: <20100408022941.0DC8218284C@deliverator5.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 tazaki at sfc.wide.ad.jp changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #814 is|0 |1 obsolete| | --- Comment #5 from tazaki at sfc.wide.ad.jp 2010-04-07 22:29:40 EDT --- Created an attachment (id=816) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=816) changeset 6173 6ff89f45451c -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 20:02:12 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Wed, 7 Apr 2010 23:02:12 -0400 Subject: [Ns-bugs] [Bug 859] Output interface estimation for the source address bound socket in IPv4 Raw socket In-Reply-To: References: Message-ID: <20100408030212.223615E404C@deliverator4.gatech.edu> http://www.nsnam.org/bugzilla/show_bug.cgi?id=859 tazaki at sfc.wide.ad.jp changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |VERIFIED Resolution| |FIXED --- Comment #6 from tazaki at sfc.wide.ad.jp 2010-04-07 23:02:11 EDT --- (In reply to comment #5) > Created an attachment (id=816) --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=816) [details] > changeset 6173 6ff89f45451c I've added test code and already pushed. test code is: changeset: 6175:910171e4181c -- Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From code at nsnam.ece.gatech.edu Wed Apr 7 22:37:41 2010 From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu) Date: Thu, 8 Apr 2010 01:37:41 -0400 Subject: [Ns-bugs] [Bug 866] New: WiMAX mobility models not aggregated to Node Message-ID: http://www.nsnam.org/bugzilla/show_bug.cgi?id=866 Summary: WiMAX mobility models not aggregated to Node Product: ns-3 Version: pre-release Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: wimax AssignedTo: amine.ismail at sophia.inria.fr ReportedBy: tomh at tomh.org CC: ns-bugs at isi.edu, amine.ismail at sophia.inria.fr Estimated Hours: 0.0 Mobility models in WiMAX are added to the Phy, not to the node, and they are not aggregated. in wimax-phy.h, there is: /** * \return the mobility model of the device */ virtual Ptr