2009-08-20 03:42:51 EDT ---
it passes regression tests, but I don't know how to commit, do you mean change
the resolution to "fixed" and click "commit" and it will be applied in
ns-3-dev?
(In reply to comment #5)
> if --regression still passes, please commit
>
> I see that m_static_nextValid and m_static_next are unused: can you kill them
> in a separate patch if I am right and --regression still passes ?
>
--
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 Aug 21 06:31:49 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 21 Aug 2009 09:31:49 -0400
Subject: [Ns-bugs] [Bug 664] New: memory fault/dangling pointer problems in
tcp-socket-impl.cc, with suggested fixes
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=664
Summary: memory fault/dangling pointer problems in tcp-socket-
impl.cc, with suggested fixes
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: internet-stack
AssignedTo: ns-bugs at isi.edu
ReportedBy: wdr at bell-labs.com
Estimated Hours: 0.0
Created an attachment (id=566)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=566)
Revised version of source. Works for me. However, it's based on 3.5 stable, not
dev.
I found the following bugs in stable version 3.5 of internet-stack/tcp-socket-
impl.cc. Symptoms are crashing with a memory fault and/or getting stuck in a
loop when the simulation ends.
1. TcpSocketImpl::PersistTimeout() uses m_pendingData without verifying that
it's not 0. It's clear that the lines up to and including SendPacket() should
be guarded with a test, as in:
if (!m_pendingData) {
Ptr = m_pendingData->...; ...;
m_tcp->SendPacket (...);
}
But I'm not sure about last few lines, where it reschedules the event.
Should those be invoked if m_pendingData is 0?
2. Sometimes the socket is deleted when there is a pending m_rextEvent. As a
result, the scheduler calls the handler function on the freed space, with the
usual nasty result.
I think the solution is to cancel the event in TcpSocketImpl::ProcessEvent(),
when it detects that the socket is closed:
if (m_state == CLOSED && saveState != CLOSED && m_endPoint != 0) {
.....
m_rextEvent.Cancel (); // ADD
}
3. Under heavy load, the m_persistEvent event isn't always canceled before the
socket is deleted. I don't know where it's supposed to be canceled, but one
solution is to cancel it in the d'tor. And for safety, it would be nice to
assert that the other events are no longer active.
Eg, add the following to TcpSocketImpl::~TcpSocketImpl():
NS_ASSERT (m_retxEvent.IsExpired ());
NS_ASSERT (m_lastAckEvent.IsExpired ());
NS_ASSERT (m_delAckEvent.IsExpired ());
m_persistEvent.Cancel ();
1 & 3 are also a problem in version 3.4.
I've attached a modified version that works for me. It's based on stable
version 3.5.
--
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 Aug 21 11:09:21 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 21 Aug 2009 14:09:21 -0400
Subject: [Ns-bugs] [Bug 665] New: Need Tutorial Sectino on Config Path and
Tracing Use
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=665
Summary: Need Tutorial Sectino on Config Path and Tracing Use
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: documentation
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
Our users are obviously having a hard time understanding how to construct
correct config paths and use them. We need to have a tutorial section that
does some hand-holding and detailed explanation of what is going on.
In conjunction with some new NS_LOG messages in config.cc we need to walk
through examples, and follow in detail, how one would figure out what goes
right and what goes wrong in this area.
--
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 Aug 21 12:24:18 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 21 Aug 2009 15:24:18 -0400
Subject: [Ns-bugs] [Bug 660] NormalVariable RNG's first returned value is
not expected
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=660
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #8 from Tom Henderson 2009-08-21 15:24:17 EDT ---
(In reply to comment #7)
> it passes regression tests, but I don't know how to commit, do you mean change
> the resolution to "fixed" and click "commit" and it will be applied in
> ns-3-dev?
No, bugzilla is not linked to the repository in that way. I'll contact you
about 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.
From code at nsnam.ece.gatech.edu Fri Aug 21 14:09:18 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 21 Aug 2009 17:09:18 -0400
Subject: [Ns-bugs] [Bug 666] New: wifi rates off by factor of 1000000 in
ascii output
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=666
Summary: wifi rates off by factor of 1000000 in ascii output
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: trivial
Priority: P5
Component: wifi
AssignedTo: ns-bugs at isi.edu
ReportedBy: nowatkom at gatech.edu
Estimated Hours: 0.0
The ascii output for wifi rates is off by a factor of 1000000.
This is fixed by changing line 139 of
ns-3-dev/src/devices/wifi/supported-rates.cc
The current line is:
os << (rate) << "mbs";
The proposed fix is:
os << (rate/1000000) << "mbs";
Current snip of output from /examples/wifi-ap.cc is:
PHYTX mode=wifia-6mbs ns3::WifiMacHeader (MGT_BEACON ToDS=0, FromDS=0,
MoreFrag=0, Retry=0, MoreData=0 Duration/ID=0us, DA=ff:ff:ff:ff:ff:ff,
SA=00:00:00:00:00:03, BSSID=00:00:00:00:00:03, FragNumber=0, SeqNumber=0)
ns3::MgtProbeResponseHeader (ssid=wifi-default, rates=[*6000000mbs 9000000mbs
12000000mbs 18000000mbs 24000000mbs 36000000mbs 48000000mbs 54000000mbs])
ns3::WifiMacTrailer ()
Snip of output from /examples/wifi-ap.cc after changing line 139:
PHYTX mode=wifia-6mbs ns3::WifiMacHeader (MGT_BEACON ToDS=0, FromDS=0,
MoreFrag=0, Retry=0, MoreData=0 Duration/ID=0us, DA=ff:ff:ff:ff:ff:ff,
SA=00:00:00:00:00:03, BSSID=00:00:00:00:00:03, FragNumber=0, SeqNumber=0)
ns3::MgtProbeResponseHeader (ssid=wifi-default, rates=[*6mbs 9mbs 12mbs 18mbs
24mbs 36mbs 48mbs 54mbs]) ns3::WifiMacTrailer ()
--
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 Sat Aug 22 20:57:06 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sat, 22 Aug 2009 23:57:06 -0400
Subject: [Ns-bugs] [Bug 659] Static routing with support for metrics and
longest-prefix-match-first support
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=659
Bug 659 depends on bug 634, which changed state.
Bug 634 Summary: [PATCH] Feature to grab Network Length out of Ipv4Mask
http://www.nsnam.org/bugzilla/show_bug.cgi?id=634
What |Old Value |New Value
----------------------------------------------------------------------------
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 Sat Aug 22 20:57:06 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sat, 22 Aug 2009 23:57:06 -0400
Subject: [Ns-bugs] [Bug 634] [PATCH] Feature to grab Network Length out of
Ipv4Mask
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=634
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Tom Henderson 2009-08-22 23:57:06 EDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > What about improving the implementation to detect a leading slash, and also
> > allow these strings?
> >
> > Ipv4Mask ("/32")
> > Ipv4Mask ("/24")
> > etc.
>
> Sounds like a good idea.
>
> > > (Ipv6Prefix::Ipv6Prefix(uint8_t) DOES exist).
> > >
> > > Also Ipv6Prefix class didn't seem to have a convention for function name to
> > > simply get the length, so I used this one.
> > I didn't quite understand the above comment-- you are saying that you invented
> > "GetMaskLength()" because there was no corresponding "GetPrefixLength()"
> > function in IPv6? Should you also add a similar length function to
> > Ipv6Prefix?
>
> Since Ipv4 stuff seems to talk about Masks (class name: Ipv4Mask) and Ipv6
> talks about prefixes (Ipv6Prefix) I went with "Mask" here just to keep with
> what seemed to be convention on Ipv4 side. So it's just whether this should be
> called GetPrefixLength() or GetMaskLength().
I elected to change this to GetPrefixLength(), for future IPv6 alignment, and
because prefix length is a common term in IPv4 (strictly speaking, mask length
is 32 bits, I suppose). changeset 0488cf67d707
I also added the option to specify masks as "/yy" string notation in the
constructor. changeset dc159c3d34ee
--
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 Aug 23 04:28:38 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 07:28:38 -0400
Subject: [Ns-bugs] [Bug 667] New: patches to enable ECMP in global routing
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
Summary: patches to enable ECMP in global routing
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: routing
AssignedTo: ns-bugs at isi.edu
ReportedBy: wilsonwk at ee.cityu.edu.hk
Estimated Hours: 0.0
Created an attachment (id=567)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=567)
1) Patch to amend CandidateQueue class
*** Introduction ***
As of changeset 258cf77942bc, the global routing implementation does not
consider equal-cost-multi-paths (ECMP) when building routing tables on nodes.
The patches included in this bug report is intended to enhance the global
routing implementation in this respect.
** Usage node ***
Apply the following patches in the order listed below (from 1) to 2) to 3))
1) enable-ecmp-change-candidate-queue-to-consider-lsa-type-when-ordering.patch
2) enable-ecmp-in-global-routing.patch
3) enable-ecmp-add-ns-log-info.patch
Set the "RandomEcmpRouting" attribute to true and packets are routed uniformly
at random on ECMP. To disable random routing among ECMP, set the attribute to
false.
There exists several methods to balance traffic among several ECMP, but
currently only pure-random is implemented.
*** Change node ***
Four major changes to global routing implementation are listed below
- Amended CandidateQueue class so that network SPFVertex is always chosen
before router SPFVertex when they are both equal distance from the root. This
is an outstanding implementation in quagga also, according to the Kunihiro's
comment that is left in the quagga 0.98.6 source code.
- Amended GlobalRouteManagerImpl class so that it is able to store multiple
parents SPFVertex and multiple next hops from the root. Regarding updating the
list of next hops, the old list of next hops for a node is just flushed with
the new list of next hops whenever shorter paths to the node is found.
Discussion on this flushing maybe necessary in view of the comments left in the
method quagga-0.98.6/ospf_spf.c/ospf_spf_consider_nexthop ().
- Amended GlobalRouteManagerImpl class so that it now considers the case when a
candidate SPFVertex is found to have equal distance to the root with an
existing SPFVertex in the SPF tree. The amendment also allows adding multiple
route entires into a root's routing table in cases there are two or more root's
next hops for reaching a node.
- Amended Ipv4GlobalRouting class so that it can select one of the multiple
routes for a given node when there exist ECMP. Currently, only the following
selection method is implemented --- a route is selected from multiple ECMP
routes uniformly at random.
*** Reference ***
- RFC2328, Section 16.1
- quagga-0.98.6\ospfd\ospf_spf.c
--
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 Aug 23 04:29:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 07:29:39 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
--- Comment #1 from wilson thong 2009-08-23 07:29:39 EDT ---
Created an attachment (id=568)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=568)
2) Patch to amend the SPF trees calculation
--
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 Aug 23 04:30:48 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 07:30:48 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
--- Comment #2 from wilson thong 2009-08-23 07:30:48 EDT ---
Created an attachment (id=569)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=569)
3) Optional. To include more NS_LOG_INFO for debugging
--
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 Aug 23 04:31:09 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 07:31:09 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
wilson thong changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #568|2) Patch to amend the SPF |2) Patch to amend the SPF
description|trees calculation |trees calculation and global
| |routing protocol
--
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 Aug 23 04:33:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 07:33:16 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
wilson thong changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://groups.google.com/gro
| |up/ns-3-
| |users/browse_thread/thread/c
| |a11d3ab23dc67e2#
--
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 Aug 23 11:25:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 14:25:50 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
Antti M?kel? changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zarhan at cc.hut.fi
--- Comment #3 from Antti M?kel? 2009-08-23 14:25:50 EDT ---
Just in case - I hope you are aware of my patch in bug #614 - not sure if it
affects your design and how much.
--
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 Aug 23 12:37:28 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 15:37:28 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
--- Comment #4 from wilson thong 2009-08-23 15:37:28 EDT ---
Updated the "usage note" below. The fully qualified name for the attribute
should be "ns3::Ipv4GlobalRouting::RandomEcmpRouting"
(In reply to comment #0)
> Created an attachment (id=567)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=567) [details]
> 1) Patch to amend CandidateQueue class
>
> *** Introduction ***
>
> As of changeset 258cf77942bc, the global routing implementation does not
> consider equal-cost-multi-paths (ECMP) when building routing tables on nodes.
> The patches included in this bug report is intended to enhance the global
> routing implementation in this respect.
>
> ** Usage node ***
>
> Apply the following patches in the order listed below (from 1) to 2) to 3))
> 1) enable-ecmp-change-candidate-queue-to-consider-lsa-type-when-ordering.patch
> 2) enable-ecmp-in-global-routing.patch
> 3) enable-ecmp-add-ns-log-info.patch
>
> Set the "ns3::Ipv4GlobalRouting::RandomEcmpRouting" attribute to true and packets are routed uniformly
> at random on ECMP. To disable random routing among ECMP, set the attribute to
> false.
>
> There exists several methods to balance traffic among several ECMP, but
> currently only pure-random is implemented.
>
> *** Change node ***
>
> Four major changes to global routing implementation are listed below
>
> - Amended CandidateQueue class so that network SPFVertex is always chosen
> before router SPFVertex when they are both equal distance from the root. This
> is an outstanding implementation in quagga also, according to the Kunihiro's
> comment that is left in the quagga 0.98.6 source code.
>
> - Amended GlobalRouteManagerImpl class so that it is able to store multiple
> parents SPFVertex and multiple next hops from the root. Regarding updating the
> list of next hops, the old list of next hops for a node is just flushed with
> the new list of next hops whenever shorter paths to the node is found.
> Discussion on this flushing maybe necessary in view of the comments left in the
> method quagga-0.98.6/ospf_spf.c/ospf_spf_consider_nexthop ().
>
> - Amended GlobalRouteManagerImpl class so that it now considers the case when a
> candidate SPFVertex is found to have equal distance to the root with an
> existing SPFVertex in the SPF tree. The amendment also allows adding multiple
> route entires into a root's routing table in cases there are two or more root's
> next hops for reaching a node.
>
> - Amended Ipv4GlobalRouting class so that it can select one of the multiple
> routes for a given node when there exist ECMP. Currently, only the following
> selection method is implemented --- a route is selected from multiple ECMP
> routes uniformly at random.
>
> *** Reference ***
> - RFC2328, Section 16.1
> - quagga-0.98.6\ospfd\ospf_spf.c
>
--
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 Aug 23 12:41:57 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 23 Aug 2009 15:41:57 -0400
Subject: [Ns-bugs] [Bug 667] patches to enable ECMP in global routing
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=667
--- Comment #5 from wilson thong 2009-08-23 15:41:56 EDT ---
Seem bug #614 doesn't affect to logic here, just some rework on coding. ^^
And I try my best to follow closely how quagga-0.98.6 does the ECMP. As long as
we all follow quagga, I don't see the global routing design needs any big
changes.
(In reply to comment #3)
> Just in case - I hope you are aware of my patch in bug #614 - not sure if it
> affects your design and how much.
>
--
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 Aug 23 21:58:23 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 24 Aug 2009 00:58:23 -0400
Subject: [Ns-bugs] [Bug 653] NetDevice link change callback proposal
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=653
--- Comment #3 from Tom Henderson 2009-08-24 00:58:23 EDT ---
(In reply to comment #2)
> Created an attachment (id=560)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=560) [details]
> std::list => TracedCallback
>
> Update patch :
> - typedef TracedCallback to ListCallback;
> - use ListCallback in NetDevice (csma, point-to-point, wifi, emu).
>
For the moment, how about just removing the typedef until requirements for a
ListCallback are better sorted out, and just using a TracedCallback (with your
other changes)?
Plus, we need to patch CHANGES.html.
--
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 Aug 24 01:13:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 24 Aug 2009 04:13:32 -0400
Subject: [Ns-bugs] [Bug 653] NetDevice link change callback proposal
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=653
--- Comment #4 from Sebastien Vincent 2009-08-24 04:13:32 EDT ---
Created an attachment (id=570)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=570)
Use TracedCallback object in *-net-device
Update patch.
It also add code to flush IPv6 neighbor discovery cache (in Icmpv6L4Protocol)
and some text in CHANGES.html.
--
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 Aug 24 18:33:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 24 Aug 2009 21:33:37 -0400
Subject: [Ns-bugs] [Bug 660] NormalVariable RNG's first returned value is
not expected
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=660
duy changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #9 from duy 2009-08-24 21:33:36 EDT ---
pushed in changeset 4736 fef6ccee5897
--
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 Aug 24 19:02:42 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 24 Aug 2009 22:02:42 -0400
Subject: [Ns-bugs] [Bug 661] WifiMacHeader Print Control Characters
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=661
duy changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from duy 2009-08-24 22:02:42 EDT ---
pushed in changeset 4737 5e4fb3918879
--
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 Aug 25 08:01:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 25 Aug 2009 11:01:04 -0400
Subject: [Ns-bugs] [Bug 662] the GetRequestedBandwidth() function doesn't
return the correct value of BandwidthRequested
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=662
Mohamed Amine ISMAIL changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |amine.ismail 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.
From code at nsnam.ece.gatech.edu Wed Aug 26 03:35:56 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 26 Aug 2009 06:35:56 -0400
Subject: [Ns-bugs] [Bug 381] Wifi crashes on shutdown
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=381
Nicola Baldo changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #7 from Nicola Baldo 2009-08-26 06:35:56 EDT ---
I experienced this bug once again, so I am re-opening it.
This time I can reproduce it with plain ns-3-dev. See attached program below.
--
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 Aug 26 03:36:45 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 26 Aug 2009 06:36:45 -0400
Subject: [Ns-bugs] [Bug 381] Wifi crashes on shutdown
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=381
--- Comment #8 from Nicola Baldo 2009-08-26 06:36:45 EDT ---
Created an attachment (id=572)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=572)
program reproducing the 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.
From code at nsnam.ece.gatech.edu Wed Aug 26 21:23:13 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 27 Aug 2009 00:23:13 -0400
Subject: [Ns-bugs] [Bug 669] New: main-packet-printer broken
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=669
Summary: main-packet-printer broken
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: sample programs
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
Estimated Hours: 0.0
samples/main-packet-printer was not updated when the packet API was reworked.
It needs to be added to wscript and needs to be updated.
--
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 Aug 27 23:50:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 02:50:04 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
--- Comment #16 from Tom Henderson 2009-08-28 02:50:03 EDT ---
(In reply to comment #14)
> Created an attachment (id=529)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=529) [details]
> Updated example
>
> Updated example (now uses Helper's GetGlobalRouting() instead of built-in).
>
I went to check this in and decided to change the API a bit (and revised some
doxygen). The main change I made was to move the InjectRoute() API from class
Ipv4GlobalRouting to class GlobalRouter. This latter class makes more sense
IMO to store these routes; then, they do not have to be passed in from the
Ipv4GlobalRouting class (which is really intended to store the forwarding table
entries), and the helper API does not need to be changed anymore. The example
program can obtain a pointer to GlobalRouter via GetObject ().
See updated example.
Please review these revisions before I check them in.
--
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 Aug 27 23:50:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 02:50:32 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #528 is|0 |1
obsolete| |
--- Comment #17 from Tom Henderson 2009-08-28 02:50:32 EDT ---
Created an attachment (id=573)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=573)
Updated 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.
From code at nsnam.ece.gatech.edu Thu Aug 27 23:50:55 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 02:50:55 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #529 is|0 |1
obsolete| |
--- Comment #18 from Tom Henderson 2009-08-28 02:50:55 EDT ---
Created an attachment (id=574)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=574)
Updated example
--
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 Aug 28 00:37:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 03:37:26 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
--- Comment #19 from Antti M?kel? 2009-08-28 03:37:26 EDT ---
(In reply to comment #16)
> I went to check this in and decided to change the API a bit (and revised some
> doxygen). The main change I made was to move the InjectRoute() API from class
> Ipv4GlobalRouting to class GlobalRouter. This latter class makes more sense
> IMO to store these routes; then, they do not have to be passed in from the
> Ipv4GlobalRouting class (which is really intended to store the forwarding table
> entries), and the helper API does not need to be changed anymore. The example
> program can obtain a pointer to GlobalRouter via GetObject ().
> See updated example.
Makes sense to me. After all, GlobalRouter is a special case in the sense
that there *does* exist an aggregated object that you can find directly from
Node level. Should be more efficient this way instead of having to go through
all the objects in ListRouting.
Probably should create that WithdrawRoute(uint32_t) function too..should be
simple enough, just copypaste GetRoute and change the "return *j" to
"m_injectedRoutes.erase(j)".
--
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 Aug 28 07:51:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 10:51:17 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
--- Comment #20 from Tom Henderson 2009-08-28 10:51:17 EDT ---
> Probably should create that WithdrawRoute(uint32_t) function too..should be
> simple enough, just copypaste GetRoute and change the "return *j" to
> "m_injectedRoutes.erase(j)".
>
How about aligning the WithdrawRoute method with InjectRoute, and namely just
allow users to specify Network/Mask rather than a route index? The function
could search for the route and erase it if found, and assert if not found.
Users would have to explicitly call RecomputeRoutingTables to flush out the
ExternalLSA.
--
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 Aug 28 08:52:34 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 11:52:34 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
--- Comment #21 from Antti M?kel? 2009-08-28 11:52:34 EDT ---
(In reply to comment #20)
> > Probably should create that WithdrawRoute(uint32_t) function too..should be
> > simple enough, just copypaste GetRoute and change the "return *j" to
> > "m_injectedRoutes.erase(j)".
> >
>
> How about aligning the WithdrawRoute method with InjectRoute, and namely just
> allow users to specify Network/Mask rather than a route index? The function
> could search for the route and erase it if found, and assert if not found.
> Users would have to explicitly call RecomputeRoutingTables to flush out the
> ExternalLSA.
Well, I was going with the alignment to StaticRouting's RemoveRoute()-method
since no such possibility exists there, either.
I wouldn't do an assert on not finding it though - maybe return a boolean on
whether it succeeded.
Anyway, thanks for improving my 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.
From code at nsnam.ece.gatech.edu Fri Aug 28 11:44:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 28 Aug 2009 14:44:41 -0400
Subject: [Ns-bugs] [Bug 614] [PATCH] Feature to allow to injecting routes to
GlobalRouting
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=614
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #573 is|0 |1
obsolete| |
--- Comment #22 from Tom Henderson 2009-08-28 14:44:41 EDT ---
Created an attachment (id=575)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=575)
add WithdrawRoute() and RemoveInjectedRoute() methods
New api in this version
+ bool WithdrawRoute (Ipv4Address network, Ipv4Mask networkMask);
+ void RemoveInjectedRoute (uint32_t i);
--
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 Sat Aug 29 21:46:59 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 30 Aug 2009 00:46:59 -0400
Subject: [Ns-bugs] [Bug 612] example scripts
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=612
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #495 is|0 |1
obsolete| |
--- Comment #3 from Tom Henderson 2009-08-30 00:46:59 EDT ---
Created an attachment (id=576)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=576)
wifi-simple-adhoc.cc
align with 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.
From code at nsnam.ece.gatech.edu Sat Aug 29 21:47:28 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 30 Aug 2009 00:47:28 -0400
Subject: [Ns-bugs] [Bug 612] example scripts
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=612
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #496 is|0 |1
obsolete| |
--- Comment #4 from Tom Henderson 2009-08-30 00:47:28 EDT ---
Created an attachment (id=577)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=577)
wifi-simple-infra.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 Sat Aug 29 21:48:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 30 Aug 2009 00:48:15 -0400
Subject: [Ns-bugs] [Bug 612] example scripts
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=612
--- Comment #6 from Tom Henderson 2009-08-30 00:48:15 EDT ---
Created an attachment (id=579)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=579)
wifi-simple-adhoc-grid.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 Sat Aug 29 21:47:55 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 30 Aug 2009 00:47:55 -0400
Subject: [Ns-bugs] [Bug 612] example scripts
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=612
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #497 is|0 |1
obsolete| |
--- Comment #5 from Tom Henderson 2009-08-30 00:47:55 EDT ---
Created an attachment (id=578)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=578)
wifi-simple-interference.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 Sat Aug 29 21:51:38 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 30 Aug 2009 00:51:38 -0400
Subject: [Ns-bugs] [Bug 612] example scripts
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=612
Tom Henderson