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.