From code at nsnam.ece.gatech.edu Sun Nov 1 14:49:11 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 1 Nov 2009 17:49:11 -0500
Subject: [Ns-bugs] [Bug 733] OLSR MPR Computation give incorrect result
In-Reply-To:
References:
Message-ID: <20091101224911.A7C6039C0FB@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=733
Gustavo J. A. M. Carneiro changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gjcarneiro at gmail.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Gustavo J. A. M. Carneiro 2009-11-01 17:49:11 EDT ---
Please try ns-3-dev. It should be fixed now. And thanks for the good work
providing a test case.
changeset: 5471:61831e265e20
tag: tip
user: Gustavo J. A. M. Carneiro
date: Sun Nov 01 22:47:04 2009 +0000
summary: Bug 733: OLSR MPR Computation give incorrect result
--
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 Nov 2 02:45:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 2 Nov 2009 05:45:41 -0500
Subject: [Ns-bugs] [Bug 734] New: Detection of which apidefs to use fails in
some Mac systems
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=734
Summary: Detection of which apidefs to use fails in some Mac
systems
Product: ns-3
Version: ns-3-dev
Platform: Macintosh
OS/Version: Mac OS
Status: NEW
Severity: normal
Priority: P5
Component: python bindings
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
Estimated Hours: 0.0
On some Mac systems, uint64_t is "long long unsigned int" even though "long
unsigned int" is also 64 bits wide.
Need to fix the detection of which apidefs to use by considering gcc
compilation tests (to check how uint64_t is defined, long or long long?),
instead of struct.calcsize.
Reporter thread here:
http://groups.google.com/group/ns-3-users/browse_frm/thread/8e50f28113ef23ba/3c65b2baf01a9f1e?hl=en&tvc=1&q=ns-3.6+does+not+build+on+Mac+OS+10.6+%09%09%09%09#3c65b2baf01a9f1e
--
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 Nov 2 05:04:24 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 2 Nov 2009 08:04:24 -0500
Subject: [Ns-bugs] [Bug 735] New: OLSR doesn't deliver packets to upper
layers
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=735
Summary: OLSR doesn't deliver packets to upper layers
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P1
Component: routing
AssignedTo: ns-bugs at isi.edu
ReportedBy: boyko at iitp.ru
Estimated Hours: 0.0
Created an attachment (id=642)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=642)
OLSR routing usage example
OLSR routing doesn't work at all since no packets are locally delivered in
RouteInput() methods (lcb callback is not used).
Attached olsr.cc example demonstrates this. Attached olsr.patch fixes this
(contains examples/routing/olsr.cc as well).
--
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 Nov 2 05:05:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 2 Nov 2009 08:05:12 -0500
Subject: [Ns-bugs] [Bug 735] OLSR doesn't deliver packets to upper layers
In-Reply-To:
References:
Message-ID: <20091102130512.4EAA85E40D1@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=735
--- Comment #1 from Pavel Boyko 2009-11-02 08:05:12 EDT ---
Created an attachment (id=643)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=643)
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 Nov 2 12:59:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 2 Nov 2009 15:59:32 -0500
Subject: [Ns-bugs] [Bug 735] OLSR doesn't deliver packets to upper layers
In-Reply-To:
References:
Message-ID: <20091102205932.DA0A94800BB@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=735
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #2 from Tom Henderson 2009-11-02 15:59:32 EDT ---
(In reply to comment #0)
> Created an attachment (id=642)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=642) [details]
> OLSR routing usage example
>
> OLSR routing doesn't work at all since no packets are locally delivered in
> RouteInput() methods (lcb callback is not used).
I would clarify instead that OLSR routing does not work outside of the
ListRouting context (which has been documented). But OLSR does work with the
current OlsrHelper and examples that insert Olsr into a list routing protocol.
The Ipv4ListRouting class supports local delivery-- those packets never make it
to OLSR.
>
> Attached olsr.cc example demonstrates this. Attached olsr.patch fixes this
> (contains examples/routing/olsr.cc as well).
>
>+ // Local delivery
>+ NS_ASSERT (m_ipv4->GetInterfaceForDevice (idev) >= 0);
>+ int32_t iif = m_ipv4->GetInterfaceForDevice (idev);
>+ for (std::map , Ipv4InterfaceAddress>::const_iterator j = m_socketAddresses.begin ();
>+ j != m_socketAddresses.end (); ++j)
>+ {
>+ Ipv4InterfaceAddress iface = j->second;
>+ if (dst == iface.GetLocal () || dst == iface.GetBroadcast ())
>+ {
>+ NS_LOG_LOGIC ("Local delivery to " << iface.GetLocal () << ":" << iface.GetBroadcast ());
>+ lcb (p, header, iif);
>+ return true;
>+ }
>+ }
This logic is similar but not identical to ipv4-list-routing-protocol.cc. I
didn't copy the ipv4-list-routing-protocol.cc logic into olsr a while back
because I wasn't sure that it was a good idea to clone this type of code all
around the routing protocols. Instead, I think that some kind of helper
function that encapsulated the above in one place (such as non-member
non-friend in ipv4.{h,cc}) could be reusable across protocols.
--
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 Nov 2 23:45:52 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 3 Nov 2009 02:45:52 -0500
Subject: [Ns-bugs] [Bug 735] OLSR doesn't deliver packets to upper layers
In-Reply-To:
References:
Message-ID: <20091103074552.3ECFD2DC1D5@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=735
--- Comment #3 from Pavel Boyko 2009-11-03 02:45:52 EDT ---
Tom,
thank you for clarifying this point.
> I would clarify instead that OLSR routing does not work outside of the
> ListRouting context (which has been documented).
Please point me that documentation, I've definitely missed it.
> This logic is similar but not identical to ipv4-list-routing-protocol.cc. I
> didn't copy the ipv4-list-routing-protocol.cc logic into olsr a while back
> because I wasn't sure that it was a good idea to clone this type of code all
> around the routing protocols. Instead, I think that some kind of helper
> function that encapsulated the above in one place (such as non-member
> non-friend in ipv4.{h,cc}) could be reusable across protocols.
I didn't catch your resolution. Do you prefer to leave local delivery to list
routing? If so -- please document this decision in ipv4-routing-protocol.h and
I will remove local delivery code from AODV. If not, do you plan to write this
helper function to be used by all routing protocols to locally deliver packets?
For now I have AODV which can work standalone and OLSR which can't, this is
not convenient.
--
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 Nov 3 05:50:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 3 Nov 2009 08:50:47 -0500
Subject: [Ns-bugs] [Bug 735] OLSR doesn't deliver packets to upper layers
In-Reply-To:
References:
Message-ID: <20091103135047.7039848019C@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=735
--- Comment #4 from Tom Henderson 2009-11-03 08:50:47 EDT ---
(In reply to comment #3)
> Tom,
>
> thank you for clarifying this point.
>
> > I would clarify instead that OLSR routing does not work outside of the
> > ListRouting context (which has been documented).
>
> Please point me that documentation, I've definitely missed it.
It is in the manual, in the OLSR section:
http://www.nsnam.org/docs/manual/manual_95.html#SEC161
but I don't see it now documented in src/routing/olsr code. So I see how this
detail could be missed.
>
> > This logic is similar but not identical to ipv4-list-routing-protocol.cc. I
> > didn't copy the ipv4-list-routing-protocol.cc logic into olsr a while back
> > because I wasn't sure that it was a good idea to clone this type of code all
> > around the routing protocols. Instead, I think that some kind of helper
> > function that encapsulated the above in one place (such as non-member
> > non-friend in ipv4.{h,cc}) could be reusable across protocols.
>
> I didn't catch your resolution. Do you prefer to leave local delivery to list
> routing?
No, I support your proposal to make all of these protocols operate standalone--
I just would prefer to factor out the common logic such as deciding whether an
address belongs to the node.
> If so -- please document this decision in ipv4-routing-protocol.h and
> I will remove local delivery code from AODV. If not, do you plan to write this
> helper function to be used by all routing protocols to locally deliver packets?
>
> For now I have AODV which can work standalone and OLSR which can't, this is
> not convenient.
Agreed. I will suggest a small revision and post it here.
--
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 Nov 3 09:30:43 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 3 Nov 2009 12:30:43 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091103173043.E7F481801B0@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #618 is|0 |1
obsolete| |
Attachment #619 is|0 |1
obsolete| |
Bug 705 depends on bug 691, which changed state.
Bug 691 Summary: times function unsupported on mingw
http://www.nsnam.org/bugzilla/show_bug.cgi?id=691
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Josh Pelkey 2009-11-03 12:30:43 EDT ---
Created an attachment (id=644)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=644)
full patch
Ok, all I've done is used Gustavo's patch and added in the ifdefs around
AnimationInterface::SetServerPort and also in test-dumbbell where this function
is potentially called. I also moved the #include "ns3/net-anim-config.h" in
animation-interface.cc to animation-interface.h, because I needed to ifdef out
the where SetServerPort is defined.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 3 09:32:40 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 3 Nov 2009 12:32:40 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091103173240.7CFD318013F@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #7 from Josh Pelkey 2009-11-03 12:32:39 EDT ---
(In reply to comment #6)
> Created an attachment (id=644)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=644) [details]
> full patch
>
> Ok, all I've done is used Gustavo's patch and added in the ifdefs around
> AnimationInterface::SetServerPort and also in test-dumbbell where this function
> is potentially called. I also moved the #include "ns3/net-anim-config.h" in
> animation-interface.cc to animation-interface.h, because I needed to ifdef out
> the where SetServerPort is defined.
>
Also, using my patch will require that the "start of patch" that Gustavo posted
be applied first (so I shouldn't have crossed it out).
--
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 Nov 3 09:35:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 3 Nov 2009 12:35:04 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091103173504.7826520C0A7@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #619 is|1 |0
obsolete| |
--
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 Nov 4 10:03:19 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 4 Nov 2009 13:03:19 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091104180319.2D3D9180570@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #8 from Faker Moatamri 2009-11-04 13:03:16 EDT ---
Created an attachment (id=645)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=645)
Patch to make mingw building works
Hi all,
Here is a patch for this bug, I verified it works under linux and mingwin.
Please take a look at it and if it is good, I will apply it to ns-3-dev.
Basically it contains the changes done by Gustavo, I removed the includes
socket.h and in.h in point-to-point-dubbell-helper.cc (not used) and added an
include fcntl.h conditional to MINGW platform in order to support the file
operations. Josh you can if you want combine our patches and produce a final
patch if you need to add anything else. The #if I put it inside
AnimationInterface::SetServerPort sothat I don't need to put another one in
test-dumbbell and it will return false under Mingw.
Best regards
Faker Moatamri
--
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 Nov 4 10:04:59 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 4 Nov 2009 13:04:59 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091104180459.2CFFC2DC6BA@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria.
| |fr
--- Comment #9 from Faker Moatamri 2009-11-04 13:04:58 EDT ---
Hi all,
Here is a patch for this bug, I verified it works under linux and mingwin.
Please take a look at it and if it is good, I will apply it to ns-3-dev.
Basically it contains the changes done by Gustavo, I removed the includes
socket.h and in.h in point-to-point-dubbell-helper.cc (not used) and added an
include fcntl.h conditional to MINGW platform in order to support the file
operations. Josh you can if you want combine our patches and produce a final
patch if you need to add anything else. The #if I put it inside
AnimationInterface::SetServerPort sothat I don't need to put another one in
test-dumbbell and it will return false under Mingw.
Best regards
Faker Moatamri
--
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 Nov 4 10:11:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 4 Nov 2009 13:11:26 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091104181126.D0FCF20C0BC@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #10 from Faker Moatamri 2009-11-04 13:11:25 EDT ---
Sorry for duplicate posts and sorry Josh, I didn't know that you were working
on it, can you please take a look at my patch and tell me if there are some
changes that needs to be done?
Thanks
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 4 12:16:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 4 Nov 2009 15:16:47 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091104201647.6E0D91800EC@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #11 from Josh Pelkey 2009-11-04 15:16:47 EDT ---
(In reply to comment #10)
> Sorry for duplicate posts and sorry Josh, I didn't know that you were working
> on it, can you please take a look at my patch and tell me if there are some
> changes that needs to be done?
> Thanks
>
No problem. I think your patch is better, and I am happy with the changes. No
objections from me.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Nov 5 02:35:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 5 Nov 2009 05:35:41 -0500
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID: <20091105103541.BAFC35E415E@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #12 from Faker Moatamri 2009-11-05 05:35:41 EDT ---
changeset 5477 ff7b28fe6a5c
--
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 Nov 5 07:06:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 5 Nov 2009 10:06:37 -0500
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID: <20091105150637.2EA1120C129@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria.
| |fr
--- Comment #8 from Faker Moatamri 2009-11-05 10:06:36 EDT ---
I have been through the patch and I have 2 remarks:
- .project file should never be included in any patch or any repository, this
file should always be kept private
- Why in wifi-example-db.sh you changed 'name' to 'variable'? Is there any
reason why you did that?
Thanks
--
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 Thu Nov 5 13:56:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 5 Nov 2009 16:56:37 -0500
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID: <20091105215637.2010E480145@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
--- Comment #9 from Andras Varga 2009-11-05 16:56:36 EDT ---
(In reply to comment #8)
> I have been through the patch and I have 2 remarks:
> - .project file should never be included in any patch or any repository, this
> file should always be kept private
In general, yes; however, here the .project file is somewhat useful for the end
user as well. The OMNeT++ IDE is based on Eclipse, and IDE can only use the ANF
file (part of the patch) if it is within an Eclipse project. Of course the end
user could create the project himself/herself as well.
Of course you decide whether .project is useful enough to be checked in. We
included it in the patch because it's easier to delete than create.
> - Why in wifi-example-db.sh you changed 'name' to 'variable'? Is there any
> reason why you did that?
This seems to be accidental, we didn't change the database output. Sorry about
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 Fri Nov 6 00:37:18 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 6 Nov 2009 03:37:18 -0500
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID: <20091106083718.A0ADE2DC076@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
--- Comment #10 from Faker Moatamri 2009-11-06 03:37:17 EDT ---
>
> In general, yes; however, here the .project file is somewhat useful for the end
> user as well. The OMNeT++ IDE is based on Eclipse, and IDE can only use the ANF
> file (part of the patch) if it is within an Eclipse project. Of course the end
> user could create the project himself/herself as well.
>
> Of course you decide whether .project is useful enough to be checked in. We
> included it in the patch because it's easier to delete than create.
>
Ok since your have a good explanation for that, I don't mind leaving the
.project file in the patch.
>
> This seems to be accidental, we didn't change the database output. Sorry about
> it.
>
Please fix this and push the patch to the repository. If you don't have enough
rights to push it into repository, send me the latest patch and I will apply
it.
Thanks
Best regards
Faker Moatamri
--
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 Fri Nov 6 01:43:56 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 6 Nov 2009 04:43:56 -0500
Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using
SetSendCallback with heavy traffic
In-Reply-To:
References:
Message-ID: <20091106094356.BED8F2DD9CB@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=341
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria.
| |fr
--- Comment #9 from Faker Moatamri 2009-11-06 04:43:56 EDT ---
(In reply to comment #8)
> Created an attachment (id=262)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=262) [details]
> Patch to add NetDevice::SetSendReadyCallback
>
> As a starting point for a eventual soln at the Socket level. This patch adds a
> callback members NetDevice::m_sendReadyCallback, of type
> NetDevice::SendReadyCallback, and a method to set it,
> NetDevice::SetSendReadyCallback. If the callback is defined, it is invoked when
> a Packet is removed from the Queue. net-device.h has a stub definition, and
> PointToPointNetDevice has a defn that does something.
>
Hi David,
Did you test this patch? does it work?
Best regards
Faker Moatamri
--
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 Fri Nov 6 03:40:42 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 6 Nov 2009 06:40:42 -0500
Subject: [Ns-bugs] [Bug 736] New: test.py should run TestSuite's from
testpy_output_dir
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=736
Summary: test.py should run TestSuite's from testpy_output_dir
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P5
Component: build system
AssignedTo: ns-bugs at isi.edu
ReportedBy: mazo at iitp.ru
Estimated Hours: 0.0
Created an attachment (id=646)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=646)
Proposed fix.
Since all examples are run being chdir()'ed to testpy_output_dir, it might be
good to have a convenient behavior for TestSuites too.
This will keep TestSuites a little simpler (they will write just to working
directory).
Also this allows direct copy-and-paste from examples in some places or vice
versa.
P.S.
By the way, Craig, is your email box at "craigdo at ee.washington.edu" working
(sorry for importunity if any)?
--
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 Nov 6 11:08:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 6 Nov 2009 14:08:50 -0500
Subject: [Ns-bugs] [Bug 341] Get unexpected dropped packets when using
SetSendCallback with heavy traffic
In-Reply-To:
References:
Message-ID: <20091106190850.2EF62180106@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=341
--- Comment #10 from evensky at dancer.ca.sandia.gov 2009-11-06 14:08:50 EDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > Created an attachment (id=262)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=262) [details] [details]
> > Patch to add NetDevice::SetSendReadyCallback
> >
> > As a starting point for a eventual soln at the Socket level. This patch adds a
> > callback members NetDevice::m_sendReadyCallback, of type
> > NetDevice::SendReadyCallback, and a method to set it,
> > NetDevice::SetSendReadyCallback. If the callback is defined, it is invoked when
> > a Packet is removed from the Queue. net-device.h has a stub definition, and
> > PointToPointNetDevice has a defn that does something.
> >
> Hi David,
> Did you test this patch? does it work?
> Best regards
> Faker Moatamri
Faker,
This was a while ago, and I just don't recall. We're not using ns3 anymore (ns3
is great, but our problem turned out not to be a good match for ns3), so I
haven't been active in ns3 for a while. I am certain that If I had posted it to
the world I would have tested it. So it probably does what it says, but I
recall that it wasn't the eventual solution we were shooting for.
\dae
--
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 Fri Nov 6 13:41:11 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 6 Nov 2009 16:41:11 -0500
Subject: [Ns-bugs] [Bug 735] OLSR doesn't deliver packets to upper layers
In-Reply-To:
References:
Message-ID: <20091106214111.475795E40E5@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=735
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |tomh at tomh.org
Status|NEW |ASSIGNED
--- Comment #5 from Tom Henderson 2009-11-06 16:41:11 EDT ---
Created an attachment (id=647)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=647)
Ipv4 patch for assisting in local delivery
So that each routing protocol doesn't have to reimplement similar logic, this
patch adds a method to class Ipv4 called IsDestinationAddress(address, iif)
that checks whether the address for a packet arriving on interface iif is
acceptable for local delivery. It also adds an attribute that can toggle the
RFC1122 strong end host/weak end host behavior for this method (namely, the
default weak end host allows a host to receive packets on an interface even if
the destination address belongs to a different interface). Finally, it moves
this logic out of Ipv4ListRoutingProtocol.
--
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 Nov 9 09:41:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 9 Nov 2009 12:41:29 -0500
Subject: [Ns-bugs] [Bug 737] New: Backoff procedure is not envoked after ACK
or CTS timeout
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=737
Summary: Backoff procedure is not envoked after ACK or CTS
timeout
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: wifi
AssignedTo: ns-bugs at isi.edu
ReportedBy: andreev at iitp.ru
Estimated Hours: 0.0
In accordance with 9.2.8 of 802.11-2007 (Ack procedure) "If a
PHY-RXSTART.indication does not occur during the ACKTimeout interval, the
STA concludes that the transmission of the MPDU has failed, and this STA shall
invoke its backoff procedure upon expiration of the ACKTimeout interval." The
same situation is with CTS timeout.
Current implementation starts a backoff procedure inside DCA-TXOP, but only
DcfManager knows about CTS and ACK timeouts.
So, the method like "StartBackoffProcedure" shall be added to DcaTxop and
EdcaTxop, but in this case backoff procedure will be initiated from both
DcaTxop and DcfManager. What about making DcfManager the only place to start
backoff procedure for all queues?
--
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 Nov 11 03:50:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 11 Nov 2009 06:50:35 -0500
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID: <20091111115035.92A7D5E416B@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #11 from Faker Moatamri 2009-11-11 06:50:34 EDT ---
Patch applied, changeset: 5502:04acce3f7133
--
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 Thu Nov 12 00:24:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 03:24:26 -0500
Subject: [Ns-bugs] [Bug 729] IPv6 over PPP
In-Reply-To:
References:
Message-ID: <20091112082426.C070018013A@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=729
Sebastien Vincent changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Sebastien Vincent 2009-11-12 03:24:26 EDT ---
Merge in revision c305c6e122c9
--
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 Nov 12 01:49:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 04:49:58 -0500
Subject: [Ns-bugs] [Bug 738] New: CsmaNetDevice calls ReceiveErrorModel too
late
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=738
Summary: CsmaNetDevice calls ReceiveErrorModel too late
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: Florian.Schmidt at cs.rwth-aachen.de
Estimated Hours: 0.0
Overview: CsmaNetDevice::Receive is responsible for calling a ReceiveErrorModel
if set. However, it removes the Ethernet header and trailer first. This means
that for the same bit error rate, the packet error rate is lower than it should
be, because Ethernet headers/trailers can never be corrupted.
Steps to reproduce:
1) Use a simple setup that transfers packets from node A to node B.
2) Set a bit error rate.
3) Record the number of packets actually received by node B.
Actual result: The packet error rate is approximately (1-BER)^x, with x being
the packet size of payload + IP/UDP header in bits.
Expected result: The packet error rate should be approximately (1-BER)^y, with
y being the packet size of payload + IP/UDP + the 144 bits of Ethernet
header/trailer.
--
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 Nov 12 04:45:27 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 07:45:27 -0500
Subject: [Ns-bugs] [Bug 739] New: OLSR: Strange HTime value in HELLO messages
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=739
Summary: OLSR: Strange HTime value in HELLO messages
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: trivial
Priority: P3
Component: routing
AssignedTo: ns-bugs at isi.edu
ReportedBy: boyko at iitp.ru
Estimated Hours: 0.0
I see (in wireshark) that HTime field in OLSR hello messages is 3 times larger
than actual hello emission interval. I see this in the code as well:
src/routing/olsr/olsr-routing-protocol.cc:1451
hello.SetHTime (Scalar (3) * m_helloInterval);
Meanwhile RFC 3626 Page 27 says:
HTime
This field specifies the HELLO emission interval used by the
node on this particular interface, i.e., the time before the
transmission of the next HELLO (this information may be used in
advanced link sensing, see section 14). The HELLO emission
interval is represented by its mantissa (four highest bits of
Htime field) and by its exponent (four lowest bits of Htime
field). In other words:
HELLO emission interval=C*(1+a/16)*2^b [in seconds]
Please explain (in the comment inplace) or 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 Thu Nov 12 08:10:36 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 11:10:36 -0500
Subject: [Ns-bugs] [Bug 740] New: OLSR MprCompute () works wrong
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Summary: OLSR MprCompute () works wrong
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: routing
AssignedTo: ns-bugs at isi.edu
ReportedBy: andreev at iitp.ru
Estimated Hours: 0.0
Created an attachment (id=650)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=650)
Test-case
A simple tes-tcase (3x3 grid) was conducted and MPRs are selelcted wrong.
Test-case is attached and proposal fix is attached
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Nov 12 08:11:02 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 11:11:02 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091112161102.EED9F180DBE@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #1 from Kirill Andreev 2009-11-12 11:11:02 EDT ---
Created an attachment (id=651)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=651)
Propsed 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 Thu Nov 12 08:14:05 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 11:14:05 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091112161405.7E2E8180756@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Kirill Andreev changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #650 is|0 |1
obsolete| |
--- Comment #2 from Kirill Andreev 2009-11-12 11:14:05 EDT ---
Created an attachment (id=652)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=652)
Test-case
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Nov 12 13:20:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 12 Nov 2009 16:20:26 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091112212026.88B672DCCC8@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #3 from Tom Henderson 2009-11-12 16:20:26 EDT ---
(In reply to comment #2)
> Created an attachment (id=652)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=652) [details]
> Test-case
You seemingly read my mind-- I wanted to create a similar test case and rename
the existing one to OLSR header (as you did), based on the previous bug 733
that was fixed this week. The only different that I had in mind would be to
instead export a trace source for "MprChanges" that exported the MPR set every
time it changed, and hook that. But the existing GetMprSet () works fine too.
+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 Fri Nov 13 00:47:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 13 Nov 2009 03:47:16 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091113084716.E015418013E@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Kirill Andreev 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 Fri Nov 13 04:48:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 13 Nov 2009 07:48:17 -0500
Subject: [Ns-bugs] [Bug 736] test.py should run TestSuite's from
testpy_output_dir
In-Reply-To:
References:
Message-ID: <20091113124817.BD928180AD0@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=736
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |mazo at iitp.ru
Resolution| |WORKSFORME
--- Comment #1 from Andrey Mazo 2009-11-13 07:48:17 EDT ---
It seems, that calls to GetTempDir () in several appropriate places do the job
well.
So closing this bug as WORKSFORME.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Nov 13 06:32:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 13 Nov 2009 09:32:58 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091113143258.507E448005A@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Gustavo J. A. M. Carneiro changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |gjcarneiro at gmail.com
Resolution|FIXED |
--- Comment #4 from Gustavo J. A. M. Carneiro 2009-11-13 09:32:58 EDT ---
Hi, I am the (mostly-absent) maintainer of the OLSR code, but I see the patch
was committed without me having time to even look at the issue, much less
approve. While I love that a unit test was added, I have serious doubts about
the patch:
2.1 --- a/src/routing/olsr/olsr-routing-protocol.cc Thu Nov 12 14:08:51
2009 +0100
2.2 +++ b/src/routing/olsr/olsr-routing-protocol.cc Fri Nov 13 11:47:02
2009 +0300
2.3 @@ -716,6 +716,10 @@
2.4 if (max == NULL || nb_tuple->willingness >
max->willingness)
2.5 {
2.6 max = nb_tuple;
2.7 + for (TwoHopNeighborSet::iterator newCovered =
N2.begin (); newCovered != N2.end (); newCovered++)
2.8 + {
2.9 + coveredTwoHopNeighbors.insert
(newCovered->twoHopNeighborAddr);
2.10 + }
2.11 max_r = r;
2.12 }
2.13 else if (nb_tuple->willingness == max->willingness)
We are inside a typical for loop that searches for a "maximum" on a set of
values. Your change assumes that, each time a new maximum is found it will be
selected, and immediately updates the coveredTwoHopNeighbors with the
assumption that the candidate will be selected. However, as the search for
maximum continues, a new maximum may be found... This leads to potentially
prematurely considering some 2-hop neighbors already covered when in fact they
are not.
2.14 @@ -740,11 +744,12 @@
2.15 if (max != NULL)
2.16 {
2.17 mprSet.insert (max->neighborMainAddr);
2.18 - for (TwoHopNeighborSet::iterator twoHopNeigh = N2.begin ();
2.19 - twoHopNeigh != N2.end (); )
2.20 + // Remove the nodes from N2 which are now covered by a node
in the MPR set.
2.21 + for (TwoHopNeighborSet::iterator twoHopNeigh = N2.begin ();
twoHopNeigh != N2.end (); )
2.22 {
2.23 - if (twoHopNeigh->neighborMainAddr ==
max->neighborMainAddr)
2.24 + if (coveredTwoHopNeighbors.find
(twoHopNeigh->twoHopNeighborAddr) != coveredTwoHopNeighbors.end ())
2.25 {
2.26 + NS_LOG_LOGIC ("2-hop neigh. " <<
twoHopNeigh->twoHopNeighborAddr << " is already covered by an MPR.");
2.27 twoHopNeigh = N2.erase (twoHopNeigh);
2.28 }
2.29 else
This code makes use of coveredTwoHopNeighbors. In the previous version only N2
was updated and consulted in this last part of the code (step 4 of the
algorythm). It was assumed that a two-hop neighbor is covered if it is not
listed in N2 anymore, so there really was no need to update both
coveredTwoHopNeighbors and N2 at the same time, right?
It was never explained in this bug report what MPR set was being selected and
which one should in theory have been selected. Keep in mind that OLSR contains
an heuristic for find a _good_ MPR set; it is not guaranteed to find the _best_
MPR set. Find the best set is an NP-complete 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 Fri Nov 13 07:54:01 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 13 Nov 2009 10:54:01 -0500
Subject: [Ns-bugs] [Bug 672] UniformDiscPositionAllocator
In-Reply-To:
References:
Message-ID: <20091113155401.B427A39C1EC@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=672
Nicola Baldo changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Nicola Baldo 2009-11-13 10:54:01 EDT ---
changeset: 5513:2ef4be6c501a
--
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 Nov 16 03:27:07 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 06:27:07 -0500
Subject: [Ns-bugs] [Bug 738] CsmaNetDevice calls ReceiveErrorModel too late
In-Reply-To:
References:
Message-ID: <20091116112708.0194254C001@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=738
--- Comment #1 from Florian Schmidt 2009-11-16 06:27:07 EDT ---
Created an attachment (id=653)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=653)
patch to fix the bug
This is a small patch to fix the bug. Not sure it's the most beautiful
solution, especially with the duplicated header/trailer removal in both
branches, but it changes as little as possible of the code. If this is not
acceptable, I can rewrite the section slightly more to eliminate the
duplication.
Patched code compiles, and in my testing setup, the PER now seems to match the
expected rate.
--
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 Nov 16 06:59:33 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 09:59:33 -0500
Subject: [Ns-bugs] [Bug 674] EIFS is not handled correctly in
DcfManager::GetAccessGrantStart
In-Reply-To:
References:
Message-ID: <20091116145933.3B5812DC258@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=674
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #1 from Mathieu Lacage 2009-11-16 09:59:32 EDT ---
The patch looks good. If you have a test in dcf-manager-test.cc for this, you
can 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 Nov 16 07:01:07 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 10:01:07 -0500
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID: <20091116150107.8C8191555F8@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #3 from Mathieu Lacage 2009-11-16 10:01:07 EDT ---
Can you point me to the relevant piece of the standard which mandates 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 Mon Nov 16 07:18:27 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 10:18:27 -0500
Subject: [Ns-bugs] [Bug 706] Backoff counting when starting NS.
In-Reply-To:
References:
Message-ID: <20091116151828.052C915560F@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=706
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #1 from Mathieu Lacage 2009-11-16 10:18:27 EDT ---
The risk is that m_cw will not be initialized correctly when the constructor is
invoked. I suspect that the best way to do this would be to use the
Object::DoStart method I introduced a couple of days ago and move the code you
introduced here instead:
void
DcaTxop::DoStart (void)
{
// XXX... start backoff
// chainup
Dcf::DoStart ();
}
And, then, you need to make sure that the MAC layer which creates the DcaTxop
class calls its Start method:
void
NqapWifiMac::DoStart (void)
{
m_beaconDca->Start ();
m_dca->Start ();
// chainup
WifiMac::DoStart ();
}
and the same modification in all other WifiMac subclasses.
--
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 Nov 16 07:18:36 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 10:18:36 -0500
Subject: [Ns-bugs] [Bug 738] CsmaNetDevice calls ReceiveErrorModel too late
In-Reply-To:
References:
Message-ID: <20091116151836.EAC27155941@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=738
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #2 from Tom Henderson 2009-11-16 10:18:36 EDT ---
(In reply to comment #1)
> Created an attachment (id=653)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=653) [details]
> patch to fix the bug
>
> This is a small patch to fix the bug. Not sure it's the most beautiful
> solution, especially with the duplicated header/trailer removal in both
> branches, but it changes as little as possible of the code. If this is not
> acceptable, I can rewrite the section slightly more to eliminate the
> duplication.
> Patched code compiles, and in my testing setup, the PER now seems to match the
> expected rate.
I agree that this bug needs fixed. It pointed out another problem, too, which
is that the m_phyRxDropTrace inconsistently gets a packet with an Ethernet
header in one call above this code block, and without the header in the error
model call.
Attached is a patch which fixes also the drop trace issue, and removes the long
else clause.
--
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 Nov 16 07:19:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 10:19:29 -0500
Subject: [Ns-bugs] [Bug 738] CsmaNetDevice calls ReceiveErrorModel too late
In-Reply-To:
References:
Message-ID: <20091116151929.2D8504801B3@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=738
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #653 is|0 |1
obsolete| |
--- Comment #3 from Tom Henderson 2009-11-16 10:19:28 EDT ---
Created an attachment (id=654)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=654)
revised 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 Mon Nov 16 07:20:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 10:20:16 -0500
Subject: [Ns-bugs] [Bug 738] CsmaNetDevice calls ReceiveErrorModel too late
In-Reply-To:
References:
Message-ID: <20091116152016.D82A62DCCC8@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=738
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu
--- Comment #4 from Tom Henderson 2009-11-16 10:20:16 EDT ---
Craig, please review and push if you are OK with this.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Nov 16 07:22:59 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 10:22:59 -0500
Subject: [Ns-bugs] [Bug 737] Backoff procedure is not envoked after ACK or
CTS timeout
In-Reply-To:
References:
Message-ID: <20091116152259.AF4E020C105@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=737
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #1 from Mathieu Lacage 2009-11-16 10:22:59 EDT ---
I am sorry but I don't see what the problem is: I believe that we do the right
thing with regard to the paragraph you quote from the standard.
Maybe you could try to give a few more details about the failing testcase you
have ?
--
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 Nov 16 10:10:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 16 Nov 2009 13:10:39 -0500
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID: <20091116181039.DB82F18037F@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
Gary Pei changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |guangyu.pei at boeing.com
--- Comment #4 from Gary Pei 2009-11-16 13:10:38 EDT ---
I don't believe the proposed patch is correct.
In IEEE Std 802.11-2007, both Table 15-2 and Table 18-5 specify slot time to be
20 microseconds for 802.11b. Also, the following is from section 19.1.2
Operational modes:
"The slot time is 20 ?s in accordance with 18.3.3, except that an optional 9 ?s
slot time may be used when the BSS consists of only ERP STAs."
Thus, for 802.11g, it can be 9 microseconds if there is no 802.11b stations.
--
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 Nov 17 00:47:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 03:47:15 -0500
Subject: [Ns-bugs] [Bug 671] RecvIfIndex tag in sockets
In-Reply-To:
References:
Message-ID: <20091117084715.B7CBB5E4183@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=671
Sebastien Vincent changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vincent at clarinet.u-strasbg.
| |fr
--- Comment #1 from Sebastien Vincent 2009-11-17 03:47:15 EDT ---
+1 to merge it.
It is interresting for radvd application to process Router Solicitation (RS) in
a clever way. The current behavior is reply with RAs on all interfaces. With
this patch I can modify radvd to just reply on the interface the RS was
received.
--
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 Nov 17 04:50:01 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 07:50:01 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091117125001.AAE0820C120@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #6 from Pavel Boyko 2009-11-17 07:50:01 EDT ---
Created an attachment (id=655)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=655)
Fix #2
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 17 04:49:38 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 07:49:38 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091117124938.69C1148018D@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Pavel Boyko changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |boyko at iitp.ru
--- Comment #5 from Pavel Boyko 2009-11-17 07:49:38 EDT ---
Hi, Gustavo,
I will support this bug while Kirill is on the vacation.
(In reply to comment #4)
> Hi, I am the (mostly-absent) maintainer of the OLSR code, but I see the patch
> was committed without me having time to even look at the issue, much less
> approve.
I'm terribly sorry, we will never do it again.
> While I love that a unit test was added, I have serious doubts about
> the patch:
I agree with you that proposed (and commited) "fix" is completely wrong.
As I can see, the real error was in the lines:
for (TwoHopNeighborSet::iterator twoHopNeigh = N2.begin ();
twoHopNeigh != N2.end (); )
{
if (twoHopNeigh->neighborMainAddr == neighbor->neighborMainAddr)
{
NS_LOG_LOGIC ("2-hop neigh. " <<
twoHopNeigh->twoHopNeighborAddr << " is already covered by an MPR.");
twoHopNeigh = N2.erase (twoHopNeigh);
}
else
{
twoHopNeigh++;
}
}
you were used to remove covered 2-hop neighbors from N2 set. This code
ignores the fact that N2 set is made of pairs {neighbor, two hop neighbor} and
that the same 2-hop neighbor can appear multiple times in N2 with different
1-hop neighbors. All this records must be deleted when two hop neighbor is
covered by MPR.
The simplest topology which illustrates this is
O -- A
| |
B -- C
where O selects MPR set and N = {A, B} N2 = {{A, C}, {B, C}}. When A is
selected as MPR your code will remove tuple {A, C} from N2 but will not remove
record {B, C} and this will case B to be erroneously selected as the second
MPR.
The proposed fix-to-fix is attached (It should be applied to ns-3-dev as is),
please take a look.
> It was never explained in this bug report what MPR set was being selected and
> which one should in theory have been selected.
I agree that current unit test topology is overcomplicated. If you don't
object I will simplify existing unit test to reproduce minimal topology drawn
above and add some more MPR selection tests. You can do this by yourself if you
like to.
> Keep in mind that OLSR contains
> an heuristic for find a _good_ MPR set; it is not guaranteed to find the _best_
> MPR set. Find the best set is an NP-complete problem...
I know. Now we are talking about correct implementation of recommended
heuristic from RFC 3626 8.3.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 Nov 17 04:51:44 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 07:51:44 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091117125144.1AD6B480106@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Pavel Boyko changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #655 is|0 |1
obsolete| |
--
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 Nov 17 04:52:33 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 07:52:33 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091117125234.004DA480073@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #7 from Pavel Boyko 2009-11-17 07:52:33 EDT ---
Created an attachment (id=656)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=656)
Fix #2, to be applied above first 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 Tue Nov 17 05:24:24 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 08:24:24 -0500
Subject: [Ns-bugs] [Bug 720] TapBridge creation fails from a script outside
the ns3 tree
In-Reply-To:
References:
Message-ID: <20091117132424.6D1E32DDB40@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=720
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mazo at iitp.ru
--- Comment #3 from Andrey Mazo 2009-11-17 08:24:23 EDT ---
(In reply to comment #1)
> The reason it works that way is to support multiple builds of different
> versions. For example, I currently have 24 different builds of different
> versions of ns-3 on my primary machine.
>
> This wouldn't work very well if the code looked into $PATH for the creator.
I suppose, it will work just fine, if you run your scripts through "./waf
--run" or "./waf shell", which can easily prepend $PATH with something like
"/home/user/repos/ns-3-dev-24/build/debug/src/devices/tap-bridge".
Another way is to enable FindCreator to search in $PATH locations before giving
up.
Hardcoding some strange paths into sources is not a good way.
EmuNetDevice has the same 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 Tue Nov 17 05:41:31 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 08:41:31 -0500
Subject: [Ns-bugs] [Bug 741] New: build failes under Ubuntu 9.10
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=741
Summary: build failes under Ubuntu 9.10
Product: ns-3
Version: ns-3.6
Platform: PC
OS/Version: Linux
Status: NEW
Severity: blocker
Priority: P5
Component: build system
AssignedTo: ns-bugs at isi.edu
ReportedBy: laurynas.riliskis at ltu.se
Estimated Hours: 0.0
Hi,
I have tester compilers gcc.4.2, 4.3, 4.4 under fresh ubuntu 9.10. All attempts
to compile ns-3-dev fails.
the version is retrieved from the mercurial
build command
->export CXX=g++-4.2
->./build.py
# Build NSC
Entering directory `nsc'
=> python scons.py linux-2.6.18
scons: Reading SConscript files ...
Checking target architecure...(cached) x86
scons: done reading SConscript files.
scons: Building targets ...
scons: `linux-2.6.18' is up to date.
scons: done building targets.
=> python scons.py linux-2.6.26
scons: Reading SConscript files ...
Checking target architecure...(cached) x86
scons: done reading SConscript files.
scons: Building targets ...
scons: `linux-2.6.26' is up to date.
scons: done building targets.
Leaving directory `nsc'
# Build NS-3
Entering directory `./ns-3-dev'
=> python waf configure --with-regression-traces ../ns-3-dev-ref-traces
--with-pybindgen ../pybindgen --with-nsc ../nsc
Checking for program g++,c++ : ok g++-4.2
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for g++ : ok
Checking for program pkg-config : ok /usr/bin/pkg-config
Checking for regression traces location : ok ../ns-3-dev-ref-traces (given)
Checking for -Wno-error=deprecated-declarations support : yes
Checking for -Wl,--soname=foo support : yes
Checking for header stdlib.h : ok
Checking for header signal.h : ok
Checking for header pthread.h : ok
Checking for high precision time implementation : 128-bit integer
Checking for header stdint.h : ok
Checking for header inttypes.h : ok
Checking for header sys/inttypes.h : not found
Checking for library rt : ok
Checking for header netpacket/packet.h : ok
Checking for header linux/if_tun.h : ok
Checking for pkg-config flags for GTK_CONFIG_STORE : ok
Checking for pkg-config flags for LIBXML2 : ok
Checking for library sqlite3 : ok
Checking for header sys/socket.h : ok
Checking for header netinet/in.h : ok
Checking for NSC location : ok ../nsc (given)
Checking for library dl : ok
Checking for NSC supported architecture i686 : ok
Checking for program python : ok /usr/bin/python
Checking for Python version >= 2.3 : ok 2.6.4
Checking for library python2.6 : ok
Checking for program python2.6-config : ok
/usr/bin/python2.6-config
Checking for header Python.h : ok
Checking for -fvisibility=hidden support : yes
Checking for pybindgen location : ok ../pybindgen
(given)
Checking for Python module pybindgen : ok
Checking for pybindgen version : ok 0.12.0.703
Checking for Python module pygccxml : ok
/usr/local/lib/python2.6/dist-packages/pygccxml/parser/declarations_cache.py:8:
DeprecationWarning: the md5 module is deprecated; use hashlib instead
import md5
Checking for pygccxml version : ok 1.0.0
Checking for program gccxml : ok /usr/bin/gccxml
Checking for gccxml version : ok 0.9.0
Checking for program sudo : ok /usr/bin/sudo
Checking for program hg : ok /usr/bin/hg
Checking for program valgrind : ok /usr/bin/valgrind
Checking for pkg-config flags for GSL : ok
---- Summary of optional NS-3 features:
Threading Primitives : enabled
Real Time Simulator : enabled
Emulated Net Device : enabled
Tap Bridge : enabled
GtkConfigStore : enabled
XmlIo : enabled
SQlite stats data output : enabled
Network Simulation Cradle : enabled
Python Bindings : enabled
Python API Scanning Support : enabled
Use sudo to set suid bit : not enabled (option --enable-sudo not selected)
Build examples and samples : enabled
Static build : not enabled (option --enable-static not
selected)
GNU Scientific Library (GSL) : enabled
'configure' finished successfully (1.756s)
=> python waf
Waf: Entering directory `/home/dev/ns3/ns-3-allinone/ns-3-dev/build'
'/home/dev/ns3/ns-3-allinone/ns-3-dev/bindings/python/ns3/__init__.py' ->
'/home/dev/ns3/ns-3-allinone/ns-3-dev/build/debug/bindings/python/ns3/__init__.py'
[372/961] cxx: src/core/log.cc -> build/debug/src/core/log_1.o
....
....
....
....
error:
[871/961] cxx: build/debug/bindings/python/ns3_module_list_routing.cc ->
build/debug/bindings/python/ns3_module_list_routing_3.o
debug/bindings/python/ns3_module_node.cc: In function ?PyObject*
_wrap_PyNs3Application_Start__0(PyNs3Application*, PyObject*, PyObject*,
PyObject**)?:
debug/bindings/python/ns3_module_node.cc:31192: error: no matching function for
call to ?ns3::Application::Start(ns3::TimeUnit<1>&)?
debug/ns3/object.h:147: note: candidates are: void ns3::Object::Start()
debug/bindings/python/ns3_module_node.cc: In function ?PyObject*
_wrap_PyNs3Application_Start__1(PyNs3Application*, PyObject*, PyObject*,
PyObject**)?:
debug/bindings/python/ns3_module_node.cc:31214: error: no matching function for
call to ?ns3::Application::Start(ns3::RandomVariable&)?
debug/ns3/object.h:147: note: candidates are: void ns3::Object::Start()
debug/bindings/python/ns3_module_node.cc: In function ?PyObject*
_wrap_PyNs3Application_Stop__0(PyNs3Application*, PyObject*, PyObject*,
PyObject**)?:
debug/bindings/python/ns3_module_node.cc:31296: error: ?class ns3::Application?
has no member named ?Stop?
debug/bindings/python/ns3_module_node.cc: In function ?PyObject*
_wrap_PyNs3Application_Stop__1(PyNs3Application*, PyObject*, PyObject*,
PyObject**)?:
debug/bindings/python/ns3_module_node.cc:31318: error: ?class ns3::Application?
has no member named ?Stop?
[872/961] cxx: build/debug/bindings/python/ns3_module_wifi.cc ->
build/debug/bindings/python/ns3_module_wifi_3.o
Waf: Leaving directory `/home/dev/ns3/ns-3-allinone/ns-3-dev/build'
Build failed
-> task failed (err #1):
{task: cxx ns3_module_node.cc -> ns3_module_node_3.o}
Traceback (most recent call last):
File "./build.py", line 117, in
sys.exit(main(sys.argv))
File "./build.py", line 108, in main
build_ns3(config)
File "./build.py", line 56, in build_ns3
run_command(["python", "waf"])
File "/home/dev/ns3/ns-3-allinone/util.py", line 24, in run_command
raise CommandError("Command %r exited with code %i" % (argv, retval))
util.CommandError: Command ['python', 'waf'] exited with code 1
info:
->uname -r
2.6.31-14-generic-pae
python Python 2.6.4
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 17 07:08:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 10:08:46 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091117150846.1C6644801C8@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #1 from Antti M?kel? 2009-11-17 10:08:45 EDT ---
Created an attachment (id=658)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=658)
Simple example on using device-bound sockets.
--
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 Nov 17 07:08:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 10:08:03 -0500
Subject: [Ns-bugs] [Bug 742] New: Implementation of SO_BINDTODEVICE
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
Summary: Implementation of SO_BINDTODEVICE
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: zarhan at cc.hut.fi
CC: tomh at tomh.org
Estimated Hours: 0.0
Created an attachment (id=657)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=657)
Patch to allow bindsockopts
As per discussion at
http://groups.google.com/group/ns-3-users/browse_thread/thread/013eb49c1ad77436
Here's first draft version of getting SO_BINDTODEVICE to work. It currently
works only on UDP sockets, and only on sending side.
TODO: Receiving side
TCP sockets
RAW sockets
(?).
However, while patch is not that complicated, it affects lots of files, as it
changes the so far pretty unused uint32_t oif in RouteOutput to Ptr
instead - and as a consequence, every inherited routing protocol and all
methods that have called RouteOutput in it's previous format.
For now, Static and Global Routing protocols actually utilize the new oif
information. Thus, the provided example works, but right now socket doesn't
check if arrived packet came in on right interface. As it stands, the patch
shouldn't BREAK anything, it's just that the added functionality isn't yet
quite complete...
Since there's a lot of changes throughout the tree (node, internet-stack and
routing), I'm hoping that this can be merged relatively quickly so I don't have
to keep recreating the diffs against newer snapshots of ns-3-dev...
The beef is in socket.cc where two methods have been added for binding a device
and checking the value. You can release the binding by binding to zero. Example
illustrates the workings quite well.
CCing Tom due to him participating in the thread on mailing list.
--
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 Nov 17 07:11:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 10:11:29 -0500
Subject: [Ns-bugs] [Bug 720] TapBridge creation fails from a script outside
the ns3 tree
In-Reply-To:
References:
Message-ID: <20091117151129.C61432DC258@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=720
--- Comment #4 from Andrey Mazo 2009-11-17 10:11:29 EDT ---
Created an attachment (id=659)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=659)
Look for {tap,emu-sock}-creator in $PATH.
1) use execlp instead of execl
2) remove FindCreator() functions
3) prepend $PATH with "build/debug/src/devices/{tap-bridge,emu}" (for debug
builds)
4) prepend $PATH in spawned processes environment with bld.env['PATH'].
This patch uses hardcoded paths like "src/devices/tap-bridge" and
"src/devices/emu" in wscripts, but this can be improved if needed.
--
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 Nov 17 07:27:08 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 10:27:08 -0500
Subject: [Ns-bugs] [Bug 741] build failes under Ubuntu 9.10
In-Reply-To:
References:
Message-ID: <20091117152708.8B9702DD3AF@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=741
Gustavo J. A. M. Carneiro changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gjcarneiro at gmail.com
--- Comment #1 from Gustavo J. A. M. Carneiro 2009-11-17 10:27:08 EDT ---
Python bindings are broken, I am working on it. For the time being, configure
with --disable-python.
--
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 Nov 17 07:35:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 10:35:15 -0500
Subject: [Ns-bugs] [Bug 622] [PATCH] Friendly names for pcap traces
In-Reply-To:
References:
Message-ID: <20091117153515.D4BB039C1A8@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=622
--- Comment #6 from Faker Moatamri 2009-11-17 10:35:15 EDT ---
Created an attachment (id=660)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=660)
Same patch against revision 5744:01f868cf15eb
Here is the same patch but against the latest revision: 5744:01f868cf15eb
--
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 Nov 17 07:36:30 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 17 Nov 2009 10:36:30 -0500
Subject: [Ns-bugs] [Bug 622] [PATCH] Friendly names for pcap traces
In-Reply-To:
References:
Message-ID: <20091117153630.4FE7820C060@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=622
--- Comment #7 from Antti M?kel? 2009-11-17 10:36:30 EDT ---
I agree about the PCapwriter approach.
--
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 Nov 17 22:24:14 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 01:24:14 -0500
Subject: [Ns-bugs] [Bug 743] New: command-line RngRun not working?
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=743
Summary: command-line RngRun not working?
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
Estimated Hours: 0.0
unconfirmed, but should be checked out:
http://groups.google.com/group/ns-3-users/browse_frm/thread/e0193e180fcd5a85
--
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 Nov 17 22:51:57 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 01:51:57 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118065157.1BA5F2DC9B9@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #2 from Tom Henderson 2009-11-18 01:51:56 EDT ---
(In reply to comment #0)
> Created an attachment (id=657)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=657) [details]
> Patch to allow bindsockopts
>
> As per discussion at
>
> http://groups.google.com/group/ns-3-users/browse_thread/thread/013eb49c1ad77436
>
> Here's first draft version of getting SO_BINDTODEVICE to work. It currently
> works only on UDP sockets, and only on sending side.
>
> TODO: Receiving side
do you have any sense of whether the receiving side will be easily achieved
(since input processing may not have visibility of this socket option at the IP
layer, or the routing protocol processing "RouteInput" may not know)?
>
> TCP sockets
> RAW sockets
>
> (?).
>
> However, while patch is not that complicated, it affects lots of files, as it
> changes the so far pretty unused uint32_t oif in RouteOutput to Ptr
> instead - and as a consequence, every inherited routing protocol and all
> methods that have called RouteOutput in it's previous format.
understood
>
> For now, Static and Global Routing protocols actually utilize the new oif
> information. Thus, the provided example works, but right now socket doesn't
> check if arrived packet came in on right interface. As it stands, the patch
> shouldn't BREAK anything, it's just that the added functionality isn't yet
> quite complete...
>
> Since there's a lot of changes throughout the tree (node, internet-stack and
> routing), I'm hoping that this can be merged relatively quickly so I don't have
> to keep recreating the diffs against newer snapshots of ns-3-dev...
>
> The beef is in socket.cc where two methods have been added for binding a device
> and checking the value. You can release the binding by binding to zero. Example
> illustrates the workings quite well.
>
> CCing Tom due to him participating in the thread on mailing list.
I support adding the function and the new socket API, and would support merging
what you have now while leaving the bug open to complete the functionality.
You hit all of the points I was looking for in the review (v6 support,
doxygen-- although note that you could add the point about releasing the
binding to the doxygen). I do have the concern about how to support on the
inbound direction.
An alternative to changing RouteOutput would be to start assigning ip interface
indexes from 1 instead of zero, but I think it is probably better to change
RouteOutput to take a NetDevice pointer since protocols in general will need to
add support for this (most have ignored this parameter), and it will not cause
soft failures for users.
--
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 Nov 18 01:44:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 04:44:25 -0500
Subject: [Ns-bugs] [Bug 744] New: Loopback-net-device is not included in
compilation
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=744
Summary: Loopback-net-device is not included in compilation
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: zarhan at cc.hut.fi
Estimated Hours: 0.0
I tried to use loopback-net-device, and turns out it's not actually compiled in
although it is documented in Doxygen. src/internet-stack/wscript doesn't have
any reference to loopback-net-device.h or .cc.
Weird part though is that the code resides in the internet-stack in the first
place - I'd think better place is src/devices.
--
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 Nov 18 01:51:21 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 04:51:21 -0500
Subject: [Ns-bugs] [Bug 744] Loopback-net-device is not included in
compilation
In-Reply-To:
References:
Message-ID: <20091118095121.C740839C1B2@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=744
--- Comment #1 from Antti M?kel? 2009-11-18 04:51:21 EDT ---
Actually, only the .h file is missing, .cc is already mentioned :)
--
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 Nov 18 02:36:51 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 05:36:51 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091118103651.6F100480171@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #8 from Gustavo J. A. M. Carneiro 2009-11-18 05:36:51 EDT ---
*sigh* I am stuck spending my time fixing Python bindings, so it might take a
while for me to get to 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 Wed Nov 18 02:41:05 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 05:41:05 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091118104106.09B9F1803C4@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #9 from Pavel Boyko 2009-11-18 05:41:05 EDT ---
(In reply to comment #8)
> *sigh* I am stuck spending my time fixing Python bindings, so it might take a
> while for me to get to this.
No problem. Meanwhile, can I commit new OLSR unit & system tests (not fixes
just tests :) without your explicit permission?
--
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 Nov 18 02:49:40 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 05:49:40 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091118104940.559862DD8B5@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #10 from Gustavo J. A. M. Carneiro 2009-11-18 05:49:40 EDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > *sigh* I am stuck spending my time fixing Python bindings, so it might take a
> > while for me to get to this.
>
> No problem. Meanwhile, can I commit new OLSR unit & system tests (not fixes
> just tests :) without your explicit permission?
Sure. Just please leave the MprCompuation code intact for a while until I have
time to review it. It is a very complicated piece of code, not easy to review
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 Nov 18 03:07:56 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 06:07:56 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118110756.57FE0155AD0@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #3 from Antti M?kel? 2009-11-18 06:07:56 EDT ---
Actually, I have...Changes are that ipv4-demuxer has now additional methods,
and I inherited the bindtonetif method from socket as a virtual function all
the way down to udpsocketimpl (so that the bound if can be put into the
endpoint as well).
So, the patch now uploaded works for UDP in both directions. I also fixed a bug
I introduced (NetDevice -> GetIfIndex does NOT correspond to
Ipv4/Ipv6interfaceindex).
TODO: TCP and RAW (and ICMP?).
--
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 Nov 18 03:08:40 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 06:08:40 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118110840.ACB531556CA@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
Antti M?kel? changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #657 is|0 |1
obsolete| |
--- Comment #4 from Antti M?kel? 2009-11-18 06:08:40 EDT ---
Created an attachment (id=661)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=661)
Patch to allow SO_BINDTODEVICE, now works for both directions with UDP
--
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 Nov 18 03:09:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 06:09:17 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118110917.4BAF220C110@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
Antti M?kel? changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #658 is|0 |1
obsolete| |
--- Comment #5 from Antti M?kel? 2009-11-18 06:09:16 EDT ---
Created an attachment (id=662)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=662)
Updated example, demonstrates both directions
--
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 Nov 18 03:11:13 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 06:11:13 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118111114.0002720C135@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #6 from Antti M?kel? 2009-11-18 06:11:13 EDT ---
Oh, I should mention - it works for UDP Ipv4-only (!) in both directions. I
didn't yet update Ipv6demuxer.
--
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 Nov 18 03:12:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 06:12:29 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118111229.9B5BD5E41A0@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #7 from Antti M?kel? 2009-11-18 06:12:29 EDT ---
(In reply to comment #6)
> Oh, I should mention - it works for UDP Ipv4-only (!) in both directions. I
> didn't yet update Ipv6demuxer.
...Although I guess there's not much to update since one doesn't EXIST...:)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 18 03:37:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 06:37:26 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091118113726.0E77C20C14B@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
Antti M?kel? changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #661 is|0 |1
obsolete| |
--- Comment #8 from Antti M?kel? 2009-11-18 06:37:25 EDT ---
Created an attachment (id=663)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=663)
SO_BINDTODEVICE socket option, now supports UDP and TCP in Ipv4 mode
Here's TCP functionality included - however, it's completely UNTESTED as of
now. Since the socket-impl itself only checks routes during connect(), I had to
add support to tcp-l4-protocol's Send() and SendPacket() functions by including
an additional Ptr parameter which I'm defaulting to zero in case
something else uses this.
Also, I haven't tested this yet, but right now it SHOULD mean that you can
change your bound interface on the fly with TCP too.
RAW sockets don't have concept of "endpoints" so not sure how to go there - I
simply changed the call in SendTo to RouteOutput reflecting the current status
so sending works, but I'm not actually sure how receiving even works with Raw
sockets - doesn't seem to go through demuxer and endpoint processing at least.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 18 04:10:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 18 Nov 2009 07:10:50 -0500
Subject: [Ns-bugs] [Bug 741] build failes under Ubuntu 9.10
In-Reply-To:
References:
Message-ID: <20091118121051.00BA15E412A@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=741
Gustavo J. A. M. Carneiro changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Gustavo J. A. M. Carneiro 2009-11-18 07:10:49 EDT ---
Should be 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 Thu Nov 19 03:39:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 19 Nov 2009 06:39:46 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091119113947.007221800E2@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
--- Comment #11 from Gustavo J. A. M. Carneiro 2009-11-19 06:39:46 EDT ---
(From update of attachment 656)
Cristal clear patch. Please 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 Thu Nov 19 03:43:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 19 Nov 2009 06:43:39 -0500
Subject: [Ns-bugs] [Bug 741] build failes under Ubuntu 9.10
In-Reply-To:
References:
Message-ID: <20091119114339.4D7A4180085@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=741
--- Comment #3 from Laurynas Riliskis 2009-11-19 06:43:39 EDT ---
can confirm that now its working.
--
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 Nov 19 07:19:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 19 Nov 2009 10:19:58 -0500
Subject: [Ns-bugs] [Bug 740] OLSR MprCompute () works wrong
In-Reply-To:
References:
Message-ID: <20091119151958.341FD20C107@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=740
Pavel Boyko changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Nov 19 22:07:38 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 20 Nov 2009 01:07:38 -0500
Subject: [Ns-bugs] [Bug 745] New: OLSR does not respond to link or address
notifications
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=745
Summary: OLSR does not respond to link or address notifications
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: routing
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
CC: gjcarneiro at gmail.com
Estimated Hours: 0.0
Follow up of bug 735.
This comment #13 from bug 735 describes a suggested path forward, mirroring
what has been done in AODV
(In reply to comment #9)
> I think there need to be a couple of things done still to finish this off:
>
> 1) these methods are null in OlsrRoutingProtocol
I can say what they are doing in AODV model:
> void
> RoutingProtocol::NotifyInterfaceUp (uint32_t i)
> {}
if not loopback, open socket, add address to m_socketAddresses and connect to
MAC layer notifications.
> void
> RoutingProtocol::NotifyInterfaceDown (uint32_t i)
> {}
disconnect from MAC layer notifications, close socket and erase record from
m_socketAddresses.
> void
> RoutingProtocol::NotifyAddAddress (uint32_t interface, Ipv4InterfaceAddress
> address)
> {}
if this is the only address of this interface, open socket and add it to
m_socketAddresses.
> void
> RoutingProtocol::NotifyRemoveAddress (uint32_t interface, Ipv4InterfaceAddress
> address)
> {}
if this interface is used by AODV, close socket and erase it from
m_socketAddresses. If interface still has addresses, open socket and add it to
m_socketAddresses using new 0-th address.
> What should be the behavior for AddAddress or NotifyInterfaceUp? If a new
> interface or a zeroth address on an interface being added, should we add to
> m_socketAddresses and open a new socket?
The logic above is somehow arbitrary and I am neutral about reproducing it in
OLSR or not.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Nov 20 01:41:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 20 Nov 2009 04:41:58 -0500
Subject: [Ns-bugs] [Bug 473] [PATCH] Alternative ns-2 trace reader
In-Reply-To:
References:
Message-ID: <20091120094158.4E10C155A5F@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=473
Rikard Nordin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rikno at ida.liu.se
--- Comment #7 from Rikard Nordin 2009-11-20 04:41:57 EDT ---
The implementation is using StaticSpeedMobilityModel, which is renamed to
ConstantVelocityMobilityModel in current version. All StaticSpeed should be
replaced by ConstantVelocity in both implementation and header.
--
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 Fri Nov 20 07:49:56 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 20 Nov 2009 10:49:56 -0500
Subject: [Ns-bugs] [Bug 555] DCF immediate access bug
In-Reply-To:
References:
Message-ID: <20091120154956.D6DDA5E417D@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=555
--- Comment #15 from Faker Moatamri 2009-11-20 10:49:55 EDT ---
Created an attachment (id=665)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=665)
New patch to work with revision 5762:ae78a8de6f5f
This is an updated patch that should apply to revision 5762:ae78a8de6f5f of
ns-3-dev. I disabled the last two tests in the dcf-manager-test.cc because they
kept on failing.
--
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 Nov 22 10:27:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sun, 22 Nov 2009 13:27:35 -0500
Subject: [Ns-bugs] [Bug 734] Detection of which apidefs to use fails in some
Mac systems
In-Reply-To:
References:
Message-ID: <20091122182735.82C6548013D@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=734
Gustavo J. A. M. Carneiro 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 Sun Nov 22 21:28:20 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 00:28:20 -0500
Subject: [Ns-bugs] [Bug 744] Loopback-net-device is not included in
compilation
In-Reply-To:
References:
Message-ID: <20091123052820.AD07A18C0AD@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=744
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #2 from Tom Henderson 2009-11-23 00:28:20 EDT ---
(In reply to comment #0)
> I tried to use loopback-net-device, and turns out it's not actually compiled in
> although it is documented in Doxygen. src/internet-stack/wscript doesn't have
> any reference to loopback-net-device.h or .cc.
>
> Weird part though is that the code resides in the internet-stack in the first
> place - I'd think better place is src/devices.
The history of this class is that there used to be no LoopbackNetDevice class;
it was fully implemented in the Internet stack module as a special kind of
device with no underlying NetDevice.
As part of the routing rework, this was refactored to be a layer-2 device. I
left it in internet stack, but upon reviewing it tonight, I agree that there is
nothing internet-specific left in the definition and might be of use outside of
internet.
Regarding the missing .h file, again this is just a policy issue about whether
this is public API to be exported. However, regardless of whether we decide to
export loopback-net-device.h (I would be OK with that), I see that we are not
effectively blocking the Doxygenation of private API such as that class. It
seems that neither the use of the \internal keyword (e.g. UdpSocketFactoryImpl)
nor the absence of the header file in the list of headers exported (e.g.
LoopbackNetDevice) leads to the class being omitted in Doxygen.
--
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 Nov 23 01:34:33 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 04:34:33 -0500
Subject: [Ns-bugs] [Bug 744] Loopback-net-device is not included in
compilation
In-Reply-To:
References:
Message-ID: <20091123093433.B86CF20C0EB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=744
--- Comment #3 from Antti M?kel? 2009-11-23 04:34:33 EDT ---
Ok - I ran into the issue when I was trying to create a, well, loopback
netdevice and for some reason #include wouldn't
work.
Example slash32-static-routing uses csmanetdevices, but this failed for me when
attempting to create socket for it since it wouldn't stay up (considering it's
not connected to anything, it's actually quite accurate).
Ptr deviceC = CreateObject ();
deviceC->SetAddress (Mac48Address::Allocate ());
nC->AddDevice (deviceC);
After I changed this to loopback netdevice and after making the loopback device
.h available things started to work. Anyway, if you have a router or any other
multi-interface node, you often bind it's "identity" to a loopback device (e.g.
OSPF router ID) so might be good idea to make this public - it's pretty
standard to bind a socket to a loopback device with routable IP - then the
packet is sent out via loopback, comes right back to node and is routed onwards
- but with the loopback's IP as source.
--
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 Nov 23 01:44:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 04:44:35 -0500
Subject: [Ns-bugs] [Bug 746] UDP uses wrong source address
In-Reply-To:
References:
Message-ID: <20091123094436.04DA6480128@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=746
--- Comment #1 from Fabian Mauchle 2009-11-23 04:44:35 EDT ---
Created an attachment (id=666)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=666)
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 Mon Nov 23 01:44:00 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 04:44:00 -0500
Subject: [Ns-bugs] [Bug 746] New: UDP uses wrong source address
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=746
Summary: UDP uses wrong source address
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: f1mauchl at hsr.ch
Estimated Hours: 0.0
When a UDP socket is bound to an address, it does not use this address as the
source address for UDP packets, but instead does a route lookup to determine
the source address. With a node that has two or more interfaces, this may
result in using the wrong 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 Mon Nov 23 02:07:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 05:07:25 -0500
Subject: [Ns-bugs] [Bug 747] New: Listening TCP socket closes on RST
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=747
Summary: Listening TCP socket closes on RST
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: f1mauchl at hsr.ch
Estimated Hours: 0.0
Created an attachment (id=667)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=667)
patch
A TCP socket in state 'Listening' changes to state 'Closed' when a (malicious)
RST packet is received. The socket should stay in state 'Listening'.
Please review the patch very closely. All unit-tests pass, but i'm not sure
whether they cover all situations.
--
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 Nov 23 02:41:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 05:41:50 -0500
Subject: [Ns-bugs] [Bug 748] New: Cloned TCP socket uses wrong source address
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=748
Summary: Cloned TCP socket uses wrong source address
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: f1mauchl at hsr.ch
Estimated Hours: 0.0
Created an attachment (id=668)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=668)
patch proposal
A listening TCP socket, to which a connection is opened, forks a new socket and
determines the source address to use from the route lookup, instead of using
the destination address to which the connection request originally has been
sent to. This leaves the connection in a state where no communication is
possible, as the endpoint of the forked socket does not match the address the
client socket is sending packets to.
To solve this, it is required to pass the packet's destination address to the
socket. This also requires changes to the Ipv4Endpoint API.
The proposed patch includes changes to the TCP forking process and the
Ipv4Endpoint API. Other protocols are only modified to match the new
Ipv4Endpoint API to be able to compile it, but do not make explicit use of 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 Mon Nov 23 04:07:19 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 07:07:19 -0500
Subject: [Ns-bugs] [Bug 732] Bugzilla test
In-Reply-To:
References:
Message-ID: <20091123120719.ED76C480172@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=732
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |mathieu.lacage at sophia.inria
| |.fr
Resolution| |INVALID
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Nov 23 05:24:43 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:24:43 -0500
Subject: [Ns-bugs] [Bug 33] Add a Simulator::DisableSchedule method
In-Reply-To:
References:
Message-ID: <20091123132443.669105E4104@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=33
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Mathieu Lacage 2009-11-23 08:24:43 EDT ---
I can't even remember what this would be used for and, again, this looks like a
duplicate of the Simulator::Stop method
--
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 Nov 23 05:26:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:26:50 -0500
Subject: [Ns-bugs] [Bug 41] Statically linked simple-p2p and simple-p2p.exe
assert
In-Reply-To:
References:
Message-ID: <20091123132650.4574320C0A4@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=41
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Mathieu Lacage 2009-11-23 08:26:50 EDT ---
This bug got fixed when we added real support for static optimized builds.
i.e., -Wl,--whole-archive is the link-time option we used to deal with this.
--
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 Nov 23 05:28:02 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:28:02 -0500
Subject: [Ns-bugs] [Bug 111] Ptr is slower than raw Packet
In-Reply-To:
References:
Message-ID: <20091123132802.18E7C15C2D0@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=111
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #1 from Mathieu Lacage 2009-11-23 08:28:01 EDT ---
ref/unref are not inlined anymore.
We still need to go back seriously to the packet code and try to figure out if
a packet free list would help. Marking as enhancement.
--
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 Nov 23 05:40:45 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:40:45 -0500
Subject: [Ns-bugs] [Bug 141] udp tx buffer is not fixed size
In-Reply-To:
References:
Message-ID: <20091123134045.1DE2C48005A@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=141
--- Comment #4 from Mathieu Lacage 2009-11-23 08:40:44 EDT ---
Maybe we should just mark this bug as WONTFIX. tom ?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Nov 23 05:48:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:48:37 -0500
Subject: [Ns-bugs] [Bug 231] Problems Using Tags in UDP Implies Problems
Elsewhere
In-Reply-To:
References:
Message-ID: <20091123134838.00361155941@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=231
--- Comment #6 from Mathieu Lacage 2009-11-23 08:48:37 EDT ---
This bug could now be fixed relatively trivially since we have a
RemovePacketTag method which could be used in UdpSocketImpl::ForwardUp
--
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 Nov 23 05:50:00 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:50:00 -0500
Subject: [Ns-bugs] [Bug 231] SocketAddressTag needs to be removed from a
packet before forwarding the packet to the user
In-Reply-To:
References:
Message-ID: <20091123135000.58CBE39C1A8@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=231
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Problems Using Tags in UDP |SocketAddressTag needs to
|Implies Problems Elsewhere |be removed from a packet
| |before forwarding the
| |packet to the user
--- Comment #7 from Mathieu Lacage 2009-11-23 08:50:00 EDT ---
updating title to more accurately reflect status of work left
--
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 Nov 23 05:50:59 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 08:50:59 -0500
Subject: [Ns-bugs] [Bug 265] more STL like methods for ns3 containers.
In-Reply-To:
References:
Message-ID: <20091123135059.EE1A6480086@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=265
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |mathieu.lacage at sophia.inria
| |.fr
Resolution| |INVALID
--- Comment #2 from Mathieu Lacage 2009-11-23 08:50:59 EDT ---
reporter never provided more information. Closing.
--
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 Nov 23 06:14:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:14:35 -0500
Subject: [Ns-bugs] [Bug 414] No ReceiveErrorModel in many devices
In-Reply-To:
References:
Message-ID: <20091123141435.846D51800BF@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=414
--- Comment #3 from Mathieu Lacage 2009-11-23 09:14:35 EDT ---
Shall we not just close this bug as INVALID since I doubt anyone will ever do
any work to make _every_ NetDevice subclass use an ErrorModel subclass.
--
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 Nov 23 06:16:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:16:41 -0500
Subject: [Ns-bugs] [Bug 437] NSC does not work when SELinux is in enforcing
mode
In-Reply-To:
References:
Message-ID: <20091123141641.7AEB120C11E@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=437
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #4 from Mathieu Lacage 2009-11-23 09:16:41 EDT ---
I [personally have never seen this bug: are we sure that this is reproducible ?
If so, what exact distribution versions ?
--
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 Nov 23 06:19:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:19:04 -0500
Subject: [Ns-bugs] [Bug 445] Is the class name Scalar in nstime.h
appropriate?
In-Reply-To:
References:
Message-ID: <20091123141904.A551639C42A@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=445
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #2 from Mathieu Lacage 2009-11-23 09:19:04 EDT ---
Ok, how about introducing DimensionLess and deprecating Scalar ?
--
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 Nov 23 06:21:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:21:12 -0500
Subject: [Ns-bugs] [Bug 462] Ascii trace doesn't show tcp header at nsc using
In-Reply-To:
References:
Message-ID: <20091123142112.E2C2E180756@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=462
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |sam.jansen at gmail.com
|.fr |
--- Comment #2 from Mathieu Lacage 2009-11-23 09:21:12 EDT ---
Pinging nsc guys again: florian, sam, what do you think ?
--
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 Nov 23 06:23:57 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:23:57 -0500
Subject: [Ns-bugs] [Bug 476] make sure RNG seeds and run number show up on
ConfigStore output
In-Reply-To:
References:
Message-ID: <20091123142357.9D71C20C11D@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=476
--- Comment #4 from Mathieu Lacage 2009-11-23 09:23:57 EDT ---
I believe that we do have a global for the run number and the rng seed. We just
need to add support for globals on config stores
related to bug 184: finish Gtk/ConfigStore
--
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 Nov 23 06:27:14 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:27:14 -0500
Subject: [Ns-bugs] [Bug 521] Ipv4 global routing inefficient
In-Reply-To:
References:
Message-ID: <20091123142714.B749539C19E@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=521
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #2 from Mathieu Lacage 2009-11-23 09:27:14 EDT ---
We should start by coming up with a testcase which shows the problem and,
adding it to our testsuite to track performance regressions in that code.
--
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 Nov 23 06:30:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:30:41 -0500
Subject: [Ns-bugs] [Bug 385] Add a generic "sequence number" class
In-Reply-To:
References:
Message-ID: <20091123143041.BF1575E4156@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=385
--- Comment #8 from Fabian Mauchle 2009-11-23 09:30:41 EDT ---
Created an attachment (id=669)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=669)
yet another implementaiton of a sequence
I just stumbled over this having a similar problem. As I have already
implemented my own version of a sequence number, I propose it here for review.
It seems to me that Gustavo's implementation is rather complex. I've tried to
make mine as simple as possible and it should be usable like any other basic
int type. I fully agree with Gustavo about the operators.
--
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 Nov 23 06:33:23 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:33:23 -0500
Subject: [Ns-bugs] [Bug 603] Simulator::Next is useless
In-Reply-To:
References:
Message-ID: <20091123143323.626C52DC0DB@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=603
--- Comment #2 from Mathieu Lacage 2009-11-23 09:33:23 EDT ---
I am going to mark this method as deprecated and remove it in 3.8
--
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 Nov 23 06:38:06 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:38:06 -0500
Subject: [Ns-bugs] [Bug 635] Added a "WillDrop" method to Queue class to
tell in advance if a packet will be dropped
In-Reply-To:
References:
Message-ID: <20091123143806.EAD4C39C109@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=635
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #2 from Mathieu Lacage 2009-11-23 09:38:06 EDT ---
I am not sure I understand what you want to use this patch for. Could you give
some example use-cases ?
--
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 Nov 23 06:44:18 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:44:18 -0500
Subject: [Ns-bugs] [Bug 686] Reading and Writing from zero areas -
unexpected result
In-Reply-To:
References:
Message-ID: <20091123144418.9ED125E4142@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=686
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #1 from Mathieu Lacage 2009-11-23 09:44:18 EDT ---
see also
http://mailman.isi.edu/pipermail/ns-developers/2009-November/007038.html
I think that I am going to mark this as WONTFIX.
--
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 Nov 23 06:45:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 09:45:37 -0500
Subject: [Ns-bugs] [Bug 694] compilation of src/simulator/time.cc with gcc
eats up to 1.4G of RAM
In-Reply-To:
References:
Message-ID: <20091123144537.760065E4070@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=694
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |mathieu.lacage at sophia.inria
| |.fr
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 Nov 23 10:16:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 13:16:04 -0500
Subject: [Ns-bugs] [Bug 555] DCF immediate access bug
In-Reply-To:
References:
Message-ID: <20091123181604.919905E416D@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=555
TimoB changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #461 is|0 |1
obsolete| |
Attachment #665 is|0 |1
obsolete| |
--- Comment #16 from TimoB 2009-11-23 13:16:03 EDT ---
Created an attachment (id=670)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=670)
Updated patch against 5768:a07d60db8448
Updated by pulling into old hg repository.
Main problem with your patch was:
+ NS_TEST_EXPECT_MSG_EQ (Simulator::Now (), MicroSeconds
(expected.m_expectedGrantTime), "Expected access grant is now");
- NS_TEST_EXPECT_MSG_EQ (Simulator::Now (), MicroSeconds (expected.second),
"Expected access grant is now");
wrong value there.
Updated everything else. The updated test methods allow (require) specification
of the backoff slots after each AIFS.
Timo
--
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 Nov 23 14:24:05 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 23 Nov 2009 17:24:05 -0500
Subject: [Ns-bugs] [Bug 437] NSC does not work when SELinux is in enforcing
mode
In-Reply-To:
References:
Message-ID: <20091123222405.28F6515407B@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=437
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |craigdo at ee.washington.edu
Resolution| |INVALID
--- Comment #5 from Craig Dowell 2009-11-23 17:24:04 EDT ---
I did see this problem when it was reported. It was a permissions issue
(google for "cannot restore segment prot after reloc") and there were a flurry
of bug reports all over everywhere when people first started running into it as
SELinux made it into 2.6 kernels.
I installed ns-3 on Fedora 11 a week or so ago which does come with SELinux
enabled and I can confirm that this no longer happens.
I believe this was fixed in selinux-policy-targeted-1.17.30-3.9 so I took the
liberty of resolving this bug as invalid (not our fault).
--
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 Nov 23 21:01:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 00:01:50 -0500
Subject: [Ns-bugs] [Bug 746] UDP uses wrong source address
In-Reply-To:
References:
Message-ID: <20091124050150.3AE8A480161@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=746
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |tomh at tomh.org
Resolution| |FIXED
--- Comment #2 from Tom Henderson 2009-11-24 00:01:49 EDT ---
(In reply to comment #1)
> Created an attachment (id=666)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=666) [details]
> patch
changeset: f6f3e7bae1a4
--
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 Nov 23 21:05:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 00:05:25 -0500
Subject: [Ns-bugs] [Bug 141] udp tx buffer is not fixed size
In-Reply-To:
References:
Message-ID: <20091124050525.20FC6480086@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=141
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #5 from Tom Henderson 2009-11-24 00:05:24 EDT ---
(In reply to comment #4)
> Maybe we should just mark this bug as WONTFIX. tom ?
I have no plans to work on this enhancement. WONTFIX ok for me.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Nov 23 21:09:44 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 00:09:44 -0500
Subject: [Ns-bugs] [Bug 414] No ReceiveErrorModel in SimpleNetDevice
In-Reply-To:
References:
Message-ID: <20091124050944.906C92DD9CB@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=414
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ns-bugs at isi.edu,
| |tomh at tomh.org
Component|devices |node module
Summary|No ReceiveErrorModel in |No ReceiveErrorModel in
|many devices |SimpleNetDevice
--- Comment #4 from Tom Henderson 2009-11-24 00:09:44 EDT ---
(In reply to comment #3)
> Shall we not just close this bug as INVALID since I doubt anyone will ever do
> any work to make _every_ NetDevice subclass use an ErrorModel subclass.
I will take it. I want to add this to SimpleNetDevice. Changed title to
reflect.
--
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 Mon Nov 23 21:12:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 00:12:46 -0500
Subject: [Ns-bugs] [Bug 184] GtkConfigStore do not support ConfigureDefault
In-Reply-To:
References:
Message-ID: <20091124051246.DF5C05E415A@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=184
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #2 from Tom Henderson 2009-11-24 00:12:45 EDT ---
*** Bug 476 has been marked as a duplicate of this bug. ***
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Mon Nov 23 21:12:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 00:12:46 -0500
Subject: [Ns-bugs] [Bug 476] make sure RNG seeds and run number show up on
ConfigStore output
In-Reply-To:
References:
Message-ID: <20091124051246.579AB5E4125@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=476
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #5 from Tom Henderson 2009-11-24 00:12:45 EDT ---
(In reply to comment #4)
> I believe that we do have a global for the run number and the rng seed. We just
> need to add support for globals on config stores
>
> related to bug 184: finish Gtk/ConfigStore
*** This bug has been marked as a duplicate of bug 184 ***
--
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 Nov 23 21:15:55 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 00:15:55 -0500
Subject: [Ns-bugs] [Bug 521] Ipv4 global routing inefficient
In-Reply-To:
References:
Message-ID: <20091124051555.312A41557BC@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=521
--- Comment #3 from Tom Henderson 2009-11-24 00:15:54 EDT ---
(In reply to comment #2)
> We should start by coming up with a testcase which shows the problem and,
> adding it to our testsuite to track performance regressions in that code.
Agree.
A version of the patch attached to this bug was previously committed. I would
be OK with changing the title to "Performance regression test needed for global
routing" or something like that, or else close this bug for now.
--
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 Nov 24 01:37:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 04:37:39 -0500
Subject: [Ns-bugs] [Bug 699] TestCase::DoRun probably should not return a
bool
In-Reply-To:
References:
Message-ID: <20091124093739.0EEDC20C11B@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=699
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu
--- Comment #1 from Mathieu Lacage 2009-11-24 04:37:38 EDT ---
assigning to craig.
--
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 Tue Nov 24 01:39:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 04:39:32 -0500
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID: <20091124093932.D0D175E4180@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |ns-bugs at isi.edu
|.fr |
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--- Comment #5 from Mathieu Lacage 2009-11-24 04:39:32 EDT ---
gary appears to agree with me that this a correct patch. Do you have more
information to add ? If not, I think I will mark this as INVALID in a day or
two.
--
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 Tue Nov 24 01:45:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 04:45:26 -0500
Subject: [Ns-bugs] [Bug 701] inline HighPrecision Max () and Min () functions
In-Reply-To:
References:
Message-ID: <20091124094527.0111D39C0E4@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=701
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |mathieu.lacage at sophia.inria
| |.fr
Resolution| |FIXED
--- Comment #3 from Mathieu Lacage 2009-11-24 04:45:26 EDT ---
changeset: bb1eea10412f
--
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 Nov 24 01:51:42 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 04:51:42 -0500
Subject: [Ns-bugs] [Bug 707] new build fail ,open solaris
In-Reply-To:
References:
Message-ID: <20091124095142.5FDB54800EF@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=707
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #1 from Mathieu Lacage 2009-11-24 04:51:42 EDT ---
We don't explicitely support this platform but if you can provide non-intrusive
patches to support it, I am sure we can merge them. If you really care about
this platform, another really helpful thing to do would be to provide a
buildbot slave we can connect to our buildbot master to ensure that your
platform keeps working once you have fixed all problems.
Anyway, from looking at the error log below, the first problem I see is that
your system might be defining a macro which we do not expect. You should try to
recompile nstime.h with the -E option send us the generated file.
--
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 Nov 24 01:53:53 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 04:53:53 -0500
Subject: [Ns-bugs] [Bug 708] SendCallback does not work with NSC
In-Reply-To:
References:
Message-ID: <20091124095354.0052E480073@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=708
--- Comment #1 from Mathieu Lacage 2009-11-24 04:53:53 EDT ---
Alberto, I know that you have done some work to deal with these issues. Could
you attach a patch to this bug report ?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 01:58:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 04:58:47 -0500
Subject: [Ns-bugs] [Bug 720] TapBridge creation fails from a script outside
the ns3 tree
In-Reply-To:
References:
Message-ID: <20091124095847.09F172DDAC9@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=720
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|craigdo at ee.washington.edu |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu
--- Comment #5 from Mathieu Lacage 2009-11-24 04:58:46 EDT ---
+1. Craig needs to ack this. assigning to 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.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 02:00:24 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:00:24 -0500
Subject: [Ns-bugs] [Bug 721] Explicit releases of Ptr<> throughout codebase
In-Reply-To:
References:
Message-ID: <20091124100024.8EC361800C0@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=721
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #1 from Mathieu Lacage 2009-11-24 05:00:24 EDT ---
I am not sure which problematic examples you have in mind but to make sure that
we correctly handle reference cycles, it is still necessary to make DoDispose
in many objects actually assign its Ptr members to 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 Tue Nov 24 02:01:43 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:01:43 -0500
Subject: [Ns-bugs] [Bug 722] tap-wifi-dumbbell.cc busted
In-Reply-To:
References:
Message-ID: <20091124100143.A555E20C0AF@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=722
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, 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 Tue Nov 24 02:02:27 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:02:27 -0500
Subject: [Ns-bugs] [Bug 725] L-2 fragmentation and RTS cannot be used at the
same time
In-Reply-To:
References:
Message-ID: <20091124100227.A85CF20C10B@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=725
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 02:04:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:04:03 -0500
Subject: [Ns-bugs] [Bug 726] Build failed OSX, CalendarScheduler
In-Reply-To:
References:
Message-ID: <20091124100403.C960420C0EB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=726
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr
--- Comment #3 from Mathieu Lacage 2009-11-24 05:04:03 EDT ---
This is a bug _in_ gcc. gcc version, please ?
gcc --version ?
--
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 Nov 24 02:04:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:04:26 -0500
Subject: [Ns-bugs] [Bug 726] Build failed OSX, CalendarScheduler
In-Reply-To:
References:
Message-ID: <20091124100426.618385E40B9@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=726
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |ns-bugs at isi.edu
|.fr |
AssignedTo|ns-bugs at isi.edu |faker.moatamri at sophia.inria
| |.fr
--
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 Tue Nov 24 02:05:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:05:25 -0500
Subject: [Ns-bugs] [Bug 730] Enabling fragmentation at run-time breaks
simulation
In-Reply-To:
References:
Message-ID: <20091124100525.CFE4120C0EE@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=730
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 02:08:07 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:08:07 -0500
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID: <20091124100807.3FD281559F2@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
--- Comment #6 from Andrey Mazo 2009-11-24 05:08:05 EDT ---
(In reply to comment #5)
> gary appears to agree with me that this a correct patch. Do you have more
> information to add ? If not, I think I will mark this as INVALID in a day or
> two.
Please, wait for Kirill to return from his vacation until next Monday
(November, 30th).
--
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 Nov 24 02:08:20 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:08:20 -0500
Subject: [Ns-bugs] [Bug 737] Backoff procedure is not envoked after ACK or
CTS timeout
In-Reply-To:
References:
Message-ID: <20091124100820.8223E2DC185@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=737
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |ns-bugs at isi.edu
|.fr |
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 02:09:38 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:09:38 -0500
Subject: [Ns-bugs] [Bug 739] OLSR: Strange HTime value in HELLO messages
In-Reply-To:
References:
Message-ID: <20091124100938.E883018015E@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=739
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |gjcarneiro at gmail.com
--
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 Tue Nov 24 02:10:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:10:47 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091124101047.D74DC2DC2B8@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|tomh at tomh.org |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |tomh at tomh.org
--
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 Tue Nov 24 02:11:18 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:11:18 -0500
Subject: [Ns-bugs] [Bug 743] command-line RngRun not working?
In-Reply-To:
References:
Message-ID: <20091124101118.31219480106@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=743
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |faker.moatamri at sophia.inria
| |.fr
--
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 Tue Nov 24 02:11:55 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:11:55 -0500
Subject: [Ns-bugs] [Bug 744] Loopback-net-device is not included in
compilation
In-Reply-To:
References:
Message-ID: <20091124101155.A4C3920C0EB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=744
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|tomh at tomh.org |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |tomh at tomh.org
--
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 Tue Nov 24 02:12:54 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:12:54 -0500
Subject: [Ns-bugs] [Bug 745] OLSR does not respond to link or address
notifications
In-Reply-To:
References:
Message-ID: <20091124101254.7423C2DC1CD@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=745
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|gjcarneiro at gmail.com |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |gjcarneiro at gmail.com
--
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 Tue Nov 24 02:13:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:13:50 -0500
Subject: [Ns-bugs] [Bug 747] Listening TCP socket closes on RST
In-Reply-To:
References:
Message-ID: <20091124101350.64E0620C0DB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=747
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |jpelkey at gatech.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 Tue Nov 24 02:14:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:14:15 -0500
Subject: [Ns-bugs] [Bug 748] Cloned TCP socket uses wrong source address
In-Reply-To:
References:
Message-ID: <20091124101415.5B127480106@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=748
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |jpelkey at gatech.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 Tue Nov 24 02:40:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:40:47 -0500
Subject: [Ns-bugs] [Bug 127] Add trace callback type information for Python
bindings
In-Reply-To:
References:
Message-ID: <20091124104047.51208180108@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=127
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria
| |.fr
AssignedTo|mathieu.lacage at sophia.inria |gjcarneiro at gmail.com
|.fr |
--
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 Nov 24 02:49:48 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:49:48 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091124104948.A025739C19D@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #9 from Antti M?kel? 2009-11-24 05:49:48 EDT ---
Ok, I have reworked the example to TCP, apparently TCP support doesn't work yet
properly - continuing work.
--
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 Nov 24 02:52:45 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 05:52:45 -0500
Subject: [Ns-bugs] [Bug 184] GtkConfigStore do not support ConfigureDefault
In-Reply-To:
References:
Message-ID: <20091124105245.99BC75E4142@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=184
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |faker.moatamri at sophia.inria
| |.fr,
| |mathieu.lacage at sophia.inria
| |.fr
AssignedTo|mathieu.lacage at sophia.inria |faker.moatamri at sophia.inria
|.fr |.fr
--
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 Nov 24 03:04:48 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:04:48 -0500
Subject: [Ns-bugs] [Bug 190] Reminder: NS_LOG_APPEND_CONTEXT
In-Reply-To:
References:
Message-ID: <20091124110448.EB2AF5E413D@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=190
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |faker.moatamri at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |faker.moatamri at sophia.inria
| |.fr
--
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 Tue Nov 24 03:06:51 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:06:51 -0500
Subject: [Ns-bugs] [Bug 231] SocketAddressTag needs to be removed from a
packet before forwarding the packet to the user
In-Reply-To:
References:
Message-ID: <20091124110651.DF6A720C10A@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=231
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |faker.moatamri at sophia.inria
| |.fr,
| |mathieu.lacage at sophia.inria
| |.fr
AssignedTo|mathieu.lacage at sophia.inria |faker.moatamri at sophia.inria
|.fr |.fr
--
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 Nov 24 03:08:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:08:58 -0500
Subject: [Ns-bugs] [Bug 381] Wifi crashes on shutdown
In-Reply-To:
References:
Message-ID: <20091124110858.0771420C0EB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=381
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |faker.moatamri at sophia.inria
| |.fr
Severity|minor |normal
--
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 Nov 24 03:09:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:09:35 -0500
Subject: [Ns-bugs] [Bug 190] Reminder: NS_LOG_APPEND_CONTEXT
In-Reply-To:
References:
Message-ID: <20091124110935.692315E4147@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=190
--- Comment #2 from Gustavo J. A. M. Carneiro 2009-11-24 06:09:35 EDT ---
I think it may be pointless to keep this bug open. It's not a bug, it's more
of a development goal...
--
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 Nov 24 03:11:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:11:25 -0500
Subject: [Ns-bugs] [Bug 381] Wifi crashes on shutdown
In-Reply-To:
References:
Message-ID: <20091124111125.9F6104800E7@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=381
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 03:17:30 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:17:30 -0500
Subject: [Ns-bugs] [Bug 492] It would be useful to have a pre-simulate state
(and post)
In-Reply-To:
References:
Message-ID: <20091124111730.87F795E412A@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=492
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P2
CC| |faker.moatamri at sophia.inria
| |.fr
--
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 Nov 24 03:19:33 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:19:33 -0500
Subject: [Ns-bugs] [Bug 602] WifiRemoteStation lacks information about the
access class of outgoing packets
In-Reply-To:
References:
Message-ID: <20091124111933.EA5624800B4@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=602
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 03:20:08 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:20:08 -0500
Subject: [Ns-bugs] [Bug 602] WifiRemoteStation lacks information about the
access class of outgoing packets
In-Reply-To:
References:
Message-ID: <20091124112008.8498E1550D2@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=602
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P2
--
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 Nov 24 03:23:02 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:23:02 -0500
Subject: [Ns-bugs] [Bug 631] RealtimeSimulatorImpl not compatible with
python bindings
In-Reply-To:
References:
Message-ID: <20091124112302.F2E9D20C0A2@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=631
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |faker.moatamri at sophia.inria
|.fr |.fr, gjcarneiro at gmail.com
AssignedTo|gjcarneiro at gmail.com |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 03:27:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:27:41 -0500
Subject: [Ns-bugs] [Bug 668] not clear which values are to be used for
QosTag::m_tid
In-Reply-To:
References:
Message-ID: <20091124112741.B971B39C0FB@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=668
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |faker.moatamri at sophia.inria
|.fr |.fr, mk.banchi at gmail.com,
| |ns-bugs at isi.edu
AssignedTo|mk.banchi at gmail.com |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 03:30:54 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:30:54 -0500
Subject: [Ns-bugs] [Bug 674] EIFS is not handled correctly in
DcfManager::GetAccessGrantStart
In-Reply-To:
References:
Message-ID: <20091124113054.2A8EE5E4147@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=674
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mathieu.lacage at sophia.inria |faker.moatamri at sophia.inria
|.fr |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 03:31:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:31:04 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091124113104.9190A5E413D@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
Antti M?kel? changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #663 is|0 |1
obsolete| |
--- Comment #10 from Antti M?kel? 2009-11-24 06:31:04 EDT ---
Created an attachment (id=671)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=671)
Fixes TCP issue
Fixes TCP issue - had a leftover in SendSinglePacket, which screwed up
Connect(). Tested with attached example.
--
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 Nov 24 03:32:19 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:32:19 -0500
Subject: [Ns-bugs] [Bug 679] channel switching causes error
In-Reply-To:
References:
Message-ID: <20091124113219.BFDC2480128@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=679
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 03:34:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:34:15 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124113415.CE4011550BF@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #6 from Mathieu Lacage 2009-11-24 06:34:15 EDT ---
Created an attachment (id=672)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=672)
solution #3
How about this 3rd solution ?
--
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 Nov 24 03:35:08 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:35:08 -0500
Subject: [Ns-bugs] [Bug 742] Implementation of SO_BINDTODEVICE
In-Reply-To:
References:
Message-ID: <20091124113508.9F46B1800BF@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=742
--- Comment #11 from Antti M?kel? 2009-11-24 06:35:08 EDT ---
Created an attachment (id=673)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=673)
Example with SO_BINDTODEVICE, uses TCP.
Example of SO_BINDTODEVICE that uses TCP. Not completely analogous to the UDP
example (UDP one *always* sends replies to interface 1, TCP naturally goes with
the flow).
In theory, you *could* change binding in the middle of a flow. However, I doubt
it can have any meaningful application. Same thing is pretty much warned
against in Linux sockets documentation, too.
One thing that should be done is that at least packet-sink application helper
should be updated to support this option.
--
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 Nov 24 03:49:52 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 06:49:52 -0500
Subject: [Ns-bugs] [Bug 739] OLSR: Strange HTime value in HELLO messages
In-Reply-To:
References:
Message-ID: <20091124114952.53A5915514A@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=739
Gustavo J. A. M. Carneiro changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Gustavo J. A. M. Carneiro 2009-11-24 06:49:51 EDT ---
changeset: 5771:a8245e39c546
--
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 Nov 24 04:08:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:08:46 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124120846.C08B81558F5@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |faker.moatamri at sophia.inria
| |.fr, ns-bugs at isi.edu
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria
| |.fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 04:12:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:12:39 -0500
Subject: [Ns-bugs] [Bug 706] Backoff counting when starting NS.
In-Reply-To:
References:
Message-ID: <20091124121239.8365848005A@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=706
Faker Moatamri changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P4
CC| |faker.moatamri at sophia.inria
| |.fr
Severity|minor |normal
--
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 Nov 24 04:12:52 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:12:52 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124121252.55B4520C0DB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #7 from Mathieu Lacage 2009-11-24 07:12:51 EDT ---
ns-3-dev:
bash-3.2$ time -p ./build/optimized/examples/wireless/wifi-wired-bridging
--nStas=4
real 278.54
user 249.31
sys 3.84
bash-3.2$ time -p ./build/optimized/examples/mesh/mesh
real 216.39
user 206.39
sys 0.02
ns-3-dev + solution #3:
bash-3.2$ time -p ./build/optimized/examples/wireless/wifi-wired-bridging
--nStas=4
real 226.54
user 209.00
sys 3.03
bash-3.2$ time -p ./build/optimized/examples/mesh/mesh
real 63.63
user 62.24
sys 0.19
--
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 Nov 24 04:28:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:28:32 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124122832.0CD3B20C0DD@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #8 from Mathieu Lacage 2009-11-24 07:28:31 EDT ---
(In reply to comment #5)
> Mathieu, could you explain me why do we need 128 bits for time at all? We
That goes back to a long discussion a long long time ago. To make it short:
- we want to make it easy for model developers to get the same simulation
results on different platforms with different floating point arithmetic units
- hence, we want to encourage avoiding the use of floating point arithmetic
- but users still need to make simple calculations which need more precision
than simple integer arithmetic
- our internal time is 64bits
- hence, user calculations need more precision than 64 bits
- hence, the easiest thing to do is to give them 64.64 (128) precision.
> always find high precision arithmetics on top of the profiles (oprofile,
> cachegrind) -- can we try to avoid them using "native" 64 bit time? More
In some models, (say, DcfManager), we use Time because it's convenient, not
because we need to. i.e., a lot of the manager code could work with simple
integer arithmetics. In fact, it was originally written that way.
> globally, I have an impression that ns-3 is too slow to practically simulate
> O(100) wifi stations with dense traffic -- do you agree?
I suspect that if you try to make 100 stations _interfere_, then, yes, you will
run into interesting problems but mainly because the underlying interference
PHY model is O(n2) and, hopefully, you can easily fix this by using a different
PHY model. Otherwise, I would be happy to help fix any optimization issue you
have with the wifi models to make them useful to you.
--
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 Nov 24 04:45:19 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:45:19 -0500
Subject: [Ns-bugs] [Bug 668] not clear which values are to be used for
QosTag::m_tid
In-Reply-To:
References:
Message-ID: <20091124124519.B738A4800EF@deliverator2.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=668
--- Comment #4 from Nicola Baldo 2009-11-24 07:45:19 EDT ---
Created an attachment (id=674)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=674)
revised patch
> To summarize, the current QosTag class was designed to be completely mac/wifi
> specific without any attempt at being generic so, while I don't see any reason
> not to make it easier to use for wifi (say, add a QosTag::SetUserPriority
> method), I also don't see much point in trying to make it more generic than
> that: It really contains a tid.
Ok. Here is a revised patch which mainly does the following:
1) stick with a wifi-specific TID
2) add QosTag::SetUserPriority for user convenience
3) add doxygen documentation (I think the lack of it was the real cause of most
confusion).
--
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 Nov 24 04:52:09 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:52:09 -0500
Subject: [Ns-bugs] [Bug 668] not clear which values are to be used for
QosTag::m_tid
In-Reply-To:
References:
Message-ID: <20091124125209.AA20B20C11E@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=668
--- Comment #5 from Mathieu Lacage 2009-11-24 07:52:09 EDT ---
please, commit.
--
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 Nov 24 04:53:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:53:17 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124125318.027852DDA8D@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #9 from Andrey Mazo 2009-11-24 07:53:16 EDT ---
(In reply to comment #6)
> Created an attachment (id=672)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=672) [details]
> solution #3
>
> How about this 3rd solution ?
Good for me.
It gets much better speed gain than others!
--
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 Nov 24 04:54:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 07:54:25 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124125425.AB5CF1800BF@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #10 from Mathieu Lacage 2009-11-24 07:54:25 EDT ---
can you review it for correctness and push if it is ok ? (all tests appear to
pass, but, who knows...)
--
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 Nov 24 05:00:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 08:00:35 -0500
Subject: [Ns-bugs] [Bug 668] not clear which values are to be used for
QosTag::m_tid
In-Reply-To:
References:
Message-ID: <20091124130035.D6F9339C1CE@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=668
Nicola Baldo changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Remaining Hours|0.2 |0.0
--- Comment #6 from Nicola Baldo 2009-11-24 08:00:35 EDT ---
(In reply to comment #5)
> please, commit.
changeset: 5771:0fad665ff307
--
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 Nov 24 05:11:59 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 08:11:59 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124131159.6D0552DDA32@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #11 from Andrey Mazo 2009-11-24 08:11:58 EDT ---
(In reply to comment #10)
> can you review it for correctness and push if it is ok ? (all tests appear to
> pass, but, who knows...)
I'll try to compare some traces for several (relatively) long-running
simulations and then push.
--
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 Nov 24 05:35:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 08:35:58 -0500
Subject: [Ns-bugs] [Bug 745] OLSR does not respond to link or address
notifications
In-Reply-To:
References:
Message-ID: <20091124133558.7156C39C120@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=745
Gustavo J. A. M. Carneiro changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #1 from Gustavo J. A. M. Carneiro 2009-11-24 08:35:58 EDT ---
This is not a bug, it's a possible enhancement. I am reluctant to work on it,
it seems rather superfluous.
(In reply to comment #0)
>
> I can say what they are doing in AODV model:
>
> > void
> > RoutingProtocol::NotifyInterfaceUp (uint32_t i)
> > {}
>
> if not loopback, open socket, add address to m_socketAddresses and connect to
> MAC layer notifications.
Sounds good.
>
> > void
> > RoutingProtocol::NotifyInterfaceDown (uint32_t i)
> > {}
>
> disconnect from MAC layer notifications, close socket and erase record from
> m_socketAddresses.
RFC 3626 does not help with these interface up/down issues. It might make
sense also to delete some data from the OLSR state, for instance neighbor
tuples using that interface, two-hop neighbors reachable by those removed
neighbors, and recompute MPR set and routing table.
>
> > void
> > RoutingProtocol::NotifyAddAddress (uint32_t interface, Ipv4InterfaceAddress
> > address)
> > {}
>
> if this is the only address of this interface, open socket and add it to
> m_socketAddresses.
Not sure what are the implications for OLSR of an interface with multiple
addresses. It probably just doesn't make sense, as it might require sending
multiple HELLOs from the same interface at the same time, each HELLO with a
different source address.
>
> > void
> > RoutingProtocol::NotifyRemoveAddress (uint32_t interface, Ipv4InterfaceAddress
> > address)
> > {}
>
> if this interface is used by AODV, close socket and erase it from
> m_socketAddresses. If interface still has addresses, open socket and add it to
> m_socketAddresses using new 0-th address.
>
> > What should be the behavior for AddAddress or NotifyInterfaceUp? If a new
> > interface or a zeroth address on an interface being added, should we add to
> > m_socketAddresses and open a new socket?
>
> The logic above is somehow arbitrary and I am neutral about reproducing it in
> OLSR or not.
--
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 Nov 24 05:51:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 08:51:12 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124135112.72B76155941@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #12 from Andrey Mazo 2009-11-24 08:51:11 EDT ---
(In reply to comment #10)
> can you review it for correctness and push if it is ok ? (all tests appear to
> pass, but, who knows...)
I've noticed, that your patch and original code will behave differently in
several situations, because you've replaced lrint() with integer devision,
which works more like floor().
Old code:
Simulator::Now() = 27000;
backoffStart = 10000;
m_slotTime = 9000;
nSlots = (Simulator::Now () - backoffStart) / m_slotTime = 1.88888;
nIntSlots = lrint (nSlots.GetDouble ()) = 2;
New code:
Simulator::Now().GetMicroSeconds() = 27;
backoffStart.GetMicroSeconds() = 10;
m_slotTimeUs = 9;
nus = 27 - 10 = 17;
nIntSlots = nus / m_slotTimeUs = 17/9 = 1;
I don't know, which of the answers is correct according to the standard.
--
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 Nov 24 06:51:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 09:51:16 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124145116.71C3A2DC169@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #13 from Mathieu Lacage 2009-11-24 09:51:15 EDT ---
oh, uhm. I suspect that the correct answer is either round to upper always or
round to lower integer always, but never round to the closest.
I have no idea what we should be doing here though.
--
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 Nov 24 07:01:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 10:01:37 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124150137.74329155787@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #14 from Pavel Boyko 2009-11-24 10:01:36 EDT ---
Mathieu,
thank you for explanations about history of Time.
> I suspect that if you try to make 100 stations _interfere_, then, yes, you will
> run into interesting problems but mainly because the underlying interference
> PHY model is O(n2) and,
Yes, now I know this too. Typical profile of large scale wifi simulation I
see:
samples % image name symbol name
2361908309 68.2932 mesh-sc
ns3::InterferenceHelper::GetEnergyDuration(double)
185529257 5.3645 mesh-sc
ns3::InterferenceHelper::CalculateNoiseInterferenceW(ns3::Ptr,
std::vector >*) const
91399806 2.6428 mesh-sc
ns3::DcfManager::GetBackoffStartFor(ns3::DcfState*)
88964737 2.5724 mesh-sc
ns3::DcfManager::GetAccessGrantStart() const
> hopefully, you can easily fix this by using a different
> PHY model.
Do you have one? We will try to optimize interference model when we'll have
some time (= students).
> Otherwise, I would be happy to help fix any optimization issue you
> have with the wifi models to make them useful to you.
Thank you! We will definitely return to wifi runtime optimizations.
--
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 Nov 24 07:24:44 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 10:24:44 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124152444.4D3062DCBE6@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #15 from Andrey Mazo 2009-11-24 10:24:43 EDT ---
(In reply to comment #13)
> oh, uhm. I suspect that the correct answer is either round to upper always or
> round to lower integer always, but never round to the closest.
>
> I have no idea what we should be doing here though.
I think, I would go for rounding to upper integer always to avoid situations
with nIntSlots == 0 and updating backoffStart to the past (but I'm not sure,
that this is bad):
Simulator::Now().GetMicroSeconds() = 17;
backoffStart.GetMicroSeconds() = 10;
m_slotTimeUs = 9;
nus = 17 - 10 = 7;
nIntSlots = nus / m_slotTimeUs = 7/9 = 0;
--
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 Nov 24 07:27:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 10:27:26 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091124152726.9347120C11B@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #16 from Mathieu Lacage 2009-11-24 10:27:26 EDT ---
(In reply to comment #14)
> > hopefully, you can easily fix this by using a different
> > PHY model.
>
> Do you have one? We will try to optimize interference model when we'll have
> some time (= students).
No, I don't have one but I wish I had time to add 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 Tue Nov 24 14:33:33 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 17:33:33 -0500
Subject: [Ns-bugs] [Bug 462] Ascii trace doesn't show tcp header at nsc using
In-Reply-To:
References:
Message-ID: <20091124223333.E00D05E414E@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=462
--- Comment #3 from Sam Jansen 2009-11-24 17:33:33 EDT ---
I don't remember all the details available. If we know the packet has NSC info
in it, then we can parse out the TCP header (I did something similar for ns-2
some time ago).
I can have a look at this next week. I agree it would certainly be desirable to
have this work.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Nov 24 14:46:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 17:46:15 -0500
Subject: [Ns-bugs] [Bug 749] New: EmuNetDevice: "Received packet with
erroneous context"
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=749
Summary: EmuNetDevice: "Received packet with erroneous context"
Product: ns-3
Version: ns-3.6
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P5
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
Estimated Hours: 0.0
Did someone accidentally break EmuNetDevice when simulator system IDs (or
whatever they're called) were introduced? I see this bug in ns-3-dev, but I
got a report from people working on NS-3.6, so it must be an old bug.
root at dark-tower:/home/gjc/projects/ns/ns-3-allinone/ns-3-dev#
NS_LOG=PingEmulationExample ./build/debug/examples/emulation/emu-ping
--deviceName=wlan0
PingEmulationExample:main(): Ping Emulation Example
PingEmulationExample:main(): Create Node
0s -1 PingEmulationExample:main(): Create Device
0s -1 PingEmulationExample:main(): Add Internet Stack
0s -1 PingEmulationExample:main(): Create IPv4 Interface
0s -1 PingEmulationExample:main(): Create V4Ping Appliation
0s -1 PingEmulationExample:main(): Run Emulation.
Received packet with erroneous context ; make sure the channels in use are
correctly updating events context when transfering events from one node to
another.
Segmentation fault
--
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 Nov 24 15:01:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 24 Nov 2009 18:01:46 -0500
Subject: [Ns-bugs] [Bug 749] EmuNetDevice: "Received packet with erroneous
context"
In-Reply-To:
References:
Message-ID: <20091124230146.63E2B20C0DB@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=749
--- Comment #1 from Gustavo J. A. M. Carneiro 2009-11-24 18:01:46 EDT ---
Created an attachment (id=675)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=675)
quick-and-dirty 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 Wed Nov 25 00:14:54 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 03:14:54 -0500
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID: <20091125081454.7376B20C11E@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
--- Comment #17 from Mathieu Lacage 2009-11-25 03:14:54 EDT ---
(In reply to comment #15)
> (In reply to comment #13)
> > oh, uhm. I suspect that the correct answer is either round to upper always or
> > round to lower integer always, but never round to the closest.
> >
> > I have no idea what we should be doing here though.
> I think, I would go for rounding to upper integer always to avoid situations
> with nIntSlots == 0 and updating backoffStart to the past (but I'm not sure,
> that this is bad):
> Simulator::Now().GetMicroSeconds() = 17;
> backoffStart.GetMicroSeconds() = 10;
> m_slotTimeUs = 9;
> nus = 17 - 10 = 7;
> nIntSlots = nus / m_slotTimeUs = 7/9 = 0;
I would support whatever you feel is appropriate if you have tested it. So,
feel free to commit a version which works for you.
--
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 Nov 25 00:16:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 03:16:58 -0500
Subject: [Ns-bugs] [Bug 739] OLSR: Strange HTime value in HELLO messages
In-Reply-To:
References:
Message-ID: <20091125081658.37F6E2DD8EA@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=739
Pavel Boyko changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #2 from Pavel Boyko 2009-11-25 03:16:57 EDT ---
(In reply to comment #1)
> changeset: 5771:a8245e39c546
You should update reference traces for PCAP based regression tests:
$ ./test.py -s routing-olsr-regression
FAIL: TestSuite routing-olsr-regression
0 of 1 tests passed (0 passed, 0 skipped, 1 failed, 0 crashed, 0 valgrind
errors)
To do so you have to:
$ cd src/routing/olsr/test/
$ grep "WRITE_VECTORS = false" *.cc
hello-regression-test.cc:const bool WRITE_VECTORS = false;
tc-regression-test.cc:const bool WRITE_VECTORS = false;
Then change these "= false" to "= true" and rerun test suite. Reference PCAP
traces will be updated. Revert changes in *.cc files and commit *.pcap ones.
--
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 Nov 25 02:09:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:09:26 -0500
Subject: [Ns-bugs] [Bug 750] New: Small Ethernet do not get padded
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=750
Summary: Small Ethernet do not get padded
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: Florian.Schmidt at cs.rwth-aachen.de
Estimated Hours: 0.0
Created an attachment (id=676)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=676)
patch to pad ethernet frames
When packets that are less than 46 bytes long reach CsmaNetDevice, it will add
header and trailer and send them out. However, these packets will be less than
the required minimum frame size of 64 bytes. This also influences the time that
the line is used by each packet.
Solution: add a check in CsmaNetDevice::AddHeader. Before adding the header and
trailer, check for the length of the packet and pad it if necessary. Small and
simple patch is attached.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 25 02:18:43 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:18:43 -0500
Subject: [Ns-bugs] [Bug 751] New: FCS for Ethernet
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=751
Summary: FCS for Ethernet
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P4
Component: node module
AssignedTo: ns-bugs at isi.edu
ReportedBy: Florian.Schmidt at cs.rwth-aachen.de
Estimated Hours: 0.0
This patch adds the creation and checking of Ethernet FCS to the
EthernetTrailer class. The "meat" is taken from the crc32 calculation routine
in the Linux kernel. Also, the flag whether to calculate a checksum was changed
from static to non-static, which is in line with how that flag is handled in
higher layer protocols, e.g., IP and UDP.
--
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 Nov 25 02:19:11 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:19:11 -0500
Subject: [Ns-bugs] [Bug 751] FCS for Ethernet
In-Reply-To:
References:
Message-ID: <20091125101911.F21A220C0AF@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=751
--- Comment #1 from Florian Schmidt 2009-11-25 05:19:11 EDT ---
Created an attachment (id=677)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=677)
patch to add FCS
--
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 Nov 25 02:21:07 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:21:07 -0500
Subject: [Ns-bugs] [Bug 750] Small Ethernet frames do not get padded
In-Reply-To:
References:
Message-ID: <20091125102107.F15481801CB@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=750
Florian Schmidt changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Small Ethernet do not get |Small Ethernet frames do
|padded |not get padded
--
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 Nov 25 02:33:53 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:33:53 -0500
Subject: [Ns-bugs] [Bug 739] OLSR: Strange HTime value in HELLO messages
In-Reply-To:
References:
Message-ID: <20091125103353.A5DD81550A8@deliverator3.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=739
--- Comment #3 from Gustavo J. A. M. Carneiro 2009-11-25 05:33:53 EDT ---
I thought I did commit new pcap files?...
--
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 Nov 25 02:52:49 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:52:49 -0500
Subject: [Ns-bugs] [Bug 752] New: Object::DoStart is not executed for
objects created at t > 0
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=752
Summary: Object::DoStart is not executed for objects created at
t > 0
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: boyko at iitp.ru
CC: mathieu.lacage at sophia.inria.fr
Estimated Hours: 0.0
It is observed, that only objects created before Simulator::Run() are
initialized via DoStart (). Attached program illustrates this. Expected output
is
A::A()
A::DoStart()
and actual is just A::A().
In particular I see no way to create and start applications dynamically at t >
0 since application start is implemented via Application::DoStart().
If Object's behavior is believed to be correct, I ask for particular
Application fix (probably revert DoStart -> Start and schedule it from
SetStartTime()).
--
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 Nov 25 02:53:27 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 05:53:27 -0500
Subject: [Ns-bugs] [Bug 752] Object::DoStart is not executed for objects
created at t >
In-Reply-To:
References:
Message-ID: <20091125105327.35FB42DD270@deliverator1.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=752
--- Comment #1 from Pavel Boyko 2009-11-25 05:53:26 EDT ---
Created an attachment (id=678)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=678)
example program
--
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 Nov 25 03:49:19 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 06:49:19 -0500
Subject: [Ns-bugs] [Bug 708] SendCallback does not work with NSC
In-Reply-To:
References:
Message-ID: <20091125114919.878E21800C0@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=708
--- Comment #2 from Alberto Blanc 2009-11-25 06:49:19 EDT ---
Mathieu, actually the only work I've done on this specific problem is to
implement the modification you suggested. In NscTcpSocketImpl::SendPendingData
I have replaced the call to NotifyDataSent with a call to NotifySend as
follows:
Simulator::ScheduleNow(&NscTcpSocketImpl::NotifySend, this, GetTxAvailable ()
);
I'm not sure the value returned by GetTxAvailable is the right number in this
case but it seems to work. I'm not 100% sure about the consequences of these
changes and I doubt they should be widely adopted.
As you suggested the "right" solution would be to have nsc inform ns when
buffer space (in nsc) is available. I was hoping it could be possible to
re-use the mechanisms used for the select/poll system calls but, at least for
the moment, I wasn't able to understand how these are implemented. I was at
least able to find where Linux does free its buffers when ACK are received. It
shouldn't be too complicated to add a function call in the Linux code to notify
ns of this event but this would require explicitly adding some lines in
tcp_input.c as well as adding a new function to the interface between nsc and
ns. The part I'm more concerned about is the need to modify the Linux code,
modifications that would be needed every time a new version is "ported" to nsc.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 25 04:46:55 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 07:46:55 -0500
Subject: [Ns-bugs] [Bug 686] Reading and Writing from zero areas -
unexpected result
In-Reply-To:
References:
Message-ID: <20091125124655.2A94D20C0AF@deliverator6.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=686
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Mathieu Lacage 2009-11-25 07:46:54 EDT ---
INVALID since this is the way the API is expected to work
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 25 04:49:49 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 07:49:49 -0500
Subject: [Ns-bugs] [Bug 752] Object::DoStart is not executed for objects
created at t >
In-Reply-To:
References:
Message-ID: <20091125124949.8E79C5E4153@deliverator4.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=752
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #2 from Mathieu Lacage 2009-11-25 07:49:49 EDT ---
(In reply to comment #0)
> It is observed, that only objects created before Simulator::Run() are
> initialized via DoStart (). Attached program illustrates this. Expected output
> is
>
> A::A()
> A::DoStart()
>
> and actual is just A::A().
>
> In particular I see no way to create and start applications dynamically at t >
> 0 since application start is implemented via Application::DoStart().
>
> If Object's behavior is believed to be correct, I ask for particular
> Application fix (probably revert DoStart -> Start and schedule it from
> SetStartTime()).
I do not believe we ever explicitely supported the dynamic creation of
applications during simulation, just like we don't support dynamically creating
devices during simulation so, it is no wonder that it does not work.
I think that the first issue is deciding whether we want to support creating
applications during the simulation. CCing tom since he will have input on that.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Nov 25 05:43:10 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 25 Nov 2009 08:43:10 -0500
Subject: [Ns-bugs] [Bug 381] Wifi crashes on shutdown
In-Reply-To:
References:
Message-ID: <20091125134310.89165180570@deliverator5.gatech.edu>
http://www.nsnam.org/bugzilla/show_bug.cgi?id=381
--- Comment #9 from Faker Moatamri 2009-11-25 08:43:10 EDT ---
Hi Nicola,
I tried your program using latest ns-3-dev 5777:a7ca957db043, using valgrind
valgrind-3.3.0 and g++-4.3.2, valgrind reports memory leaks errors but no
invalid read of size 8.
==13264== 8 bytes in 2 blocks are still reachable in loss record 1 of 4
==13264== at 0x4A06D5C: operator new(unsigned long)
(vg_replace_malloc.c:230)
==13264== by 0x52089A9: ns3::ObjectRefCount::ObjectRefCount() (object-ref-count.h:42)
==13264== by 0x51F92D3: ns3::Object::Object() (object.cc:86)
==13264== by 0x5337CCE: ns3::Scheduler::Scheduler() (scheduler.h:54)
==13264== by 0x5338E66: ns3::MapScheduler::MapScheduler()
(map-scheduler.cc:44)
==13264== by 0x5338EA9: ns3::TypeId
ns3::TypeId::AddConstructor()::Maker::Create()
(type-id.h:429)
==13264== by 0x52084E5: ns3::FunctorCallbackImpl::operator()() (callback.h:166)
==13264== by 0x522FF9F: ns3::Callback::operator()() const (callback.h:407)
==13264== by 0x522F66A: ns3::ObjectFactory::Create() const
(object-factory.cc:69)
==13264== by 0x5361BFB: ns3::Ptr
ns3::ObjectFactory::Create() const (object-factory.h:110)
==13264== by 0x53607A3:
ns3::DefaultSimulatorImpl::SetScheduler(ns3::ObjectFactory)
(default-simulator-impl.cc:92)
==13264== by 0x5348881: _ZN3ns3L7GetImplEv (simulator.cc:110)
==13264==
==13264==
==13264== 32 bytes in 2 blocks are still reachable in loss record 2 of 4
==13264== at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==13264== by 0x51F930C: ns3::Object::Object() (object.cc:86)
==13264== by 0x5361D1A: ns3::SimulatorImpl::SimulatorImpl()
(simulator-impl.h:36)
==13264== by 0x5360DC4: ns3::DefaultSimulatorImpl::DefaultSimulatorImpl()
(default-simulator-impl.cc:49)
==13264== by 0x5360E54: ns3::TypeId
ns3::TypeId::AddConstructor()::Maker::Create()
(type-id.h:429)
==13264== by 0x52084E5: ns3::FunctorCallbackImpl::operator()() (callback.h:166)
==13264== by 0x522FF9F: ns3::Callback::operator()() const (callback.h:407)
==13264== by 0x522F66A: ns3::ObjectFactory::Create() const
(object-factory.cc:69)
==13264== by 0x535AB4B: ns3::Ptr
ns3::ObjectFactory::Create() const (object-factory.h:110)
==13264== by 0x5348704: _ZN3ns3L7GetImplEv (simulator.cc:103)
==13264== by 0x5348F7B: ns3::Simulator::Cancel(ns3::EventId const&)
(simulator.cc:301)
==13264== by 0x5336C4C: ns3::EventId::Cancel() (event-id.cc:42)
==13264==
==13264==
==13264== 88 bytes in 1 blocks are still reachable in loss record 3 of 4
==13264== at 0x4A06D5C: operator new(unsigned long)
(vg_replace_malloc.c:230)
==13264== by 0x5338E9C: ns3::TypeId
ns3::TypeId::AddConstructor()::Maker::Create()
(type-id.h:429)
==13264== by 0x52084E5: ns3::FunctorCallbackImpl