Re: [ns] Multi-interface support howto
Hi sir I am just want to ask how i can create a node with two interfaces one to connect to UMTS network and another to connect to IEEE802.11. thanks
[ns] Multi-interface support howto, by Ramon Aguero---really need help!!!
Hello, I am trying to modify NS-2.29 to support multiple interface according to Adding Multiple Interface Support in NS-2 by Ramon Aguero, http://personales.unican.es/aguerocr. For routing agent, I choose AODV like some people. I encountered some problems and really need help. 1.I have two questions about Listing 5.5 in the tutorial. (1)cmnh doesn't exist and I wonder whether we should change cmnh to hdr according to listing 4.6. (2) Where should I declare the variable Iface? Should I declare it in aodv.h like declaring nIfaces, targetlist[MAX_IF] and ifqueuelist[MAX_IF] in aodv.h? 2. In Changes on the Route Table part, Ramon mentioned that a new variable interface must be added to the route entry definition. But I am not clear that in which file the route entry definition exists. Is the file aodv.h or aodv_rtable.h in aodv folder or rttable.h in routing.h folder? And in order to change the route table, how many files or classes need to be modified in total? Coul! d you give me some details to do this? It is very urgent, please help me!!! Any help and advice would be very appreciated. Thank you. Tina 用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！ _ 多个邮箱同步管理，live mail客户端万人抢用中 http://get.live.cn/product/mail.html
[ns] Multi-interface support howto, by Ramon Aguero---really need help!!!
Hello, I am trying to modify NS-2.29 to support multiple interface according to Adding Multiple Interface Support in NS-2 by Ramon Aguero, http://personales.unican.es/aguerocr. For routing agent, I choose AODV like some people. I encountered some problems and really need help. 1.I have two questions about Listing 5.5 in the tutorial. (1)cmnh doesn't exist and I wonder whether we should change cmnh to hdr according to listing 4.6. (2) Where should I declare the variable Iface? Should I declare it in aodv.h like declaring nIfaces, targetlist[MAX_IF] and ifqueuelist[MAX_IF] in aodv.h? 2. In Changes on the Route Table part, Ramon mentioned that a new variable interface must be added to the route entry definition. But I am not clear that in which file the route entry definition exists. Is the file aodv.h or aodv_rtable.h in aodv folder or rttable.h in routing.h folder? And in order to change the route table, how many files or classes need to be modified in total? Coul! d you give me some details to do this? It is very urgent, please help me!!! Any help and advice would be very appreciated. Thank you. Tina _ 用手机MSN聊天写邮件看空间，无限沟通，分享精彩！ http://mobile.msn.com.cn/
[ns] Multi-interface support howto
Hi there, Is the coding working for 802_15_4 (LR-WPAN)?
Re: [ns] Multi-interface support howto
hi,
i guess there is something wrong on ns-lib.tcl
for some reason chan is set as a usual variable. if you follow the
modifications of the document correctly, chan is used as an array in
case of mutliple interfaces.
the problem might hide somewhere in here:
if {[info exists channelType_] [info exists channel_]} {
error Can't specify both channel and channelType, error!
} elseif {[info exists channelType_] ![info exists satNodeType_]} {
# Single channel, single interface
warn Please use -channel as shown in tcl/ex/wireless-mitf.tcl
if {![info exists chan]} {
set chan [new $channelType_]
}
} elseif {[info exists channel_]} {
# Multiple channel, multiple interfaces
if {[info exists numifs_]} {
set chan(0) $channel_
} else {
set chan $channel_
}
}
otherwise chan is set wrong before. in that case i would check
instproc node-config in ns-lib.tcl
cheers,
tim
Nguyen Lan schrieb:
Hi,
bacause of you are success to build ns with multi-interface so I'd
like to ask for your help. When I run a test scenario I got that error
warning: Please use -channel as shown in tcl/ex/wireless-mitf.tcl
can't set chan(0): variable isn't array
while executing
set chan($indexch) $ch
(procedure _o3 line 3)
(Simulator add-channel line 3)
invoked from within
$ns_ add-channel 0 $chan_(0)
(file mulif.tcl line 131)
Do you have any idea ?
Cheers,
Nguyen.
Tim Elschner wrote:
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to
associate the interface.
in the forwardPacket function - which is for unicast transmissions
- i use the information stored in the map to send the packets through
the correct interface. this works fine with interface 1, but fails
vor interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and interface
0 fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't
think you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct
procedure -- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing
variable arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have
been sent to this list, it seems that a more thorough description
may be required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within
the different pieces of the simulator (tcl, c++) as well as how
routing protocols can be adapted to make use of the new feature.
The howto is entitled Adding Multiple Interface Support in NS-2
and it has been written by my colleague Jesús Pérez and myself.
I’ve uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to
improve the howto, since we would like to have it like a living
document, adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
Re: [ns] Multi-interface support howto
Hello Laurent, Nguyen, all, Thanks for the discussion. In my opinion, it's sort of difficult to compare both approaches. It seems that the work that Laurent has done is quite much more comprehensive and detailed, since it uses a different approach from what the current ns-2 architecture uses for wireless networks. I've read the document (more comments/feedback to come), but I do really find it an interesting piece of work. I'll upgrade our howto to cite it, and sorry for not having done it before. We were not aware of it; in fact in this new version I'll also cite the Miracle work; these two, which also address the multi-channel problematic, use different approaches than we do, and that's one of the reasons for not citing them. Now let me try to provide some inline comments about what Laurent said about our howto. I know that its scope is probably not too broad, but what we tried (as we had already said) is to make something to help people. I know that there were some other sources of information (and thus all of them are cited/referenced in our howto), but we still believed (due to the number of questions on the mailing list and our personal experience with such information), that there was something else that could be done. At 14:00 16/02/2007, Laurent Paquereau wrote: 1) R.Aguero et al., Adding Multiple Interface Support in NS-2 (document, http://personales.unican.es/aguerocr) This document describes changes to enable support of multiple interfaces. By to support multiple interfaces they mean to allow to have more than one wireless stack below a single routing agent on a MobileNode. All the wireless stacks are identical (same Mac/Phy). This is true, although my understanding is that this is due to the fact that there are not really many other choices, I'm pretty sure that this could be changed quite quickly. However, I fail to see a use case for this. In ad hoc routing environments (which were the main thing we had in mind), the typical case is to have different interfaces IEEE 802.11a/b/g, even bluetooth, under the same routing protocol, I think that this is achievable. In fact, something we can already do is to tweak the parameters of any of the PHY/MAC layers, so that we can mimic 802.11b and 802.11g working together (changing the energy, the transmission range, etc). On the other hand, if, e.g. you are using a WSN (with some dual 802.15.4/802.11 nodes), having more than one routing protocol would make sense to me. The routing agent code has to be modified to handle more than one wireless stack. This applies only to AODV-like routing agents, that is routing agents using the standard MobileNode, not the SRNode (DSR) or the AODVUUNode (AODV-UU) for example. Well, the main reason behind this was that most of the people developing new routing protocols for ns-2 are doing it using the MobileNode. There is more documentation, and I really believed (having personally worked with the SRNode one) that it's much simpler. This functionality is basically what is provided by Hyacinth (http://www.ecsl.cs.sunysb.edu/multichannel/), some flexibility added. To this respect their contribution is to me very similar to the resources available at http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html I can't completely agree with you here. As it is stated in the howto, we have undertaken different changes: - In the Hyacinth work, (and the corresponding updates), all nodes need to have the same number of interfaces, which is fixed. We provide a way to make this as flexible as the user wants, and in fact, we also maintain the original behavior of the simulator, so that people can still use their original scripts. - This flexibility allows, not only modifying the number of channels (either at the scenario or at the node level), but to establish to which channels the node needs to connect to. - One of the most important aspects is that the existing information didn't tackle how to modify existing routing routing protocols, and we also tackle this in the howto. Best regards, Ramón
Re: [ns] Multi-interface support howto, Ramon Submission
In fact is not the enable-debug itself but -Wall in yout CCOPT
CCOPT = -Wall
On 2/20/07, Christos Gavos [EMAIL PROTECTED] wrote:
I believe you get these warnings because you have configure with
--enable-debug. If you try to reconfigure without debug support these
should go away.
hope that helps.
Cheers,
Christos
On 2/13/07, Ramon Aguero [EMAIL PROTECTED] wrote:
Hello,
Ok, I'm glad that you solved the problems related to the extension. I don't
really know how to address these warnings or whether they are relevant (at
least the virtual destructor one should not).
Cheers,
Ramón
At 13:25 13/02/2007, Nguyen Lan wrote:
Hello Ramon et al,
My problem is that I declared nIfaces, targetlist and ifqueuelist in the
aodv.h file but out of the class declaration. Now I can recompile ns but I
still had many many warnings like that
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:49: warning:
'class TracedVar' has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:87: warning:
'class TracedInt' has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:130: warning:
'class TracedDouble' has virtual functions but non-virtual destructor
common/scheduler.h:71: warning: 'class Handler' has virtual functions but
non-virtual destructor
common/ip.cc: In member function 'virtual void
IPHeaderClass::export_offsets()':
common/ip.cc:53: warning: invalid access to non-static data member
'hdr_ip::src_' of NULL object
common/ip.cc:53: warning: (perhaps the 'offsetof' macro was used
incorrectly)
common/ip.cc:54: warning: invalid access to non-static data member
'hdr_ip::dst_' of NULL object
common/ip.cc:54: warning: (perhaps the 'offsetof' macro was used
incorrectly)
common/ip.cc:55: warning: invalid access to non-static data member
'hdr_ip::ttl_' of NULL object
common/ip.cc:55: warning: (perhaps the 'offsetof' macro was used
incorrectly)
common/ip.cc:56: warning: invalid access to non-static data member
'hdr_ip::fid_' of NULL object
common/ip.cc:56: warning: (perhaps the 'offsetof' macro was used
incorrectly)
common/ip.cc:57: warning: invalid access to non-static data member
'hdr_ip::prio_' of NULL object
common/ip.cc:57: warning: (perhaps the 'offsetof' macro was used
incorrectly)
Any idea about this is welcome.
Cheers,
Nguyen.
Nguyen Lan wrote:
Hello,
I have not declared them in common/packet.h. The only place I put them in
is aodv.h (as in the document). I think this problem came from other
place and I should read the document carefully but now I don't know yet.
Thank you very much.
Cheers,
Nguyen
Ramon Aguero wrote:
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in
common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error.
Maybe I was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of
`targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that
the problem was that in the first version of the document we did not
highlight a couple of lines (the ones that you've modified); in the
original ns-mobilenode.tcl file, these two lines started with
$arptable_ **Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT
Re: [ns] Multi-interface support howto
Nguyen, I try in this post to sum up and explicit the main differences between the approach proposed by R.Aguero et al. in their how-to and ours with the MW-Node. I hope it helps you choosing what better fits your needs. 1) R.Aguero et al., Adding Multiple Interface Support in NS-2 (document, http://personales.unican.es/aguerocr) This document describes changes to enable support of multiple interfaces. By to support multiple interfaces they mean to allow to have more than one wireless stack below a single routing agent on a MobileNode. All the wireless stacks are identical (same Mac/Phy). The routing agent code has to be modified to handle more than one wireless stack. This applies only to AODV-like routing agents, that is routing agents using the standard MobileNode, not the SRNode (DSR) or the AODVUUNode (AODV-UU) for example. This functionality is basically what is provided by Hyacinth (http://www.ecsl.cs.sunysb.edu/multichannel/), some flexibility added. To this respect their contribution is to me very similar to the resources available at http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html 2) Module-based Wireless Node (MW-Node patch + documentation, http://www.q2s.ntnu.no/~paquerea/ns.html) In the following, I focus on the main features of the MW-Node. For implementation details and design choices please refer to the documentation. A MW-Node is a standard Node (not a MobileNode) with capabilities - wireless, mobility, (energy support, not functional yet) - added by means of modules. The purpose of this new design of wireless and mobile networking support in ns2 is twofold: - to support new features such as multiple channels/multiple interfaces, and - to provide a common basis for implementation of any wireless routing protocol instead of having each routing protocol as a particular case (not to say a particular node object) as it is with the MobileNode. We distinguish between: - multiple channels: one single routing object handling several wireless interfaces possibly on different channels, and - multiple interfaces: several interfaces, possibly of different types (e.g different Mac/Phy), with one routing object handling one interface. Following these definitions, R.Aguero et al. how-to discusses multiple channels support only, not multiple interfaces support. The MW-Node supports both. Note that routing agents cannot be used directly with the MW-Node, even in the case of a node with a single interface, and need to be converted. Some guidelines are provided in the documentation. Also, the layout of the MW-Node differs from the layout of a standard MobileNode and therefore from the layout proposed by R.Aguero et al. In the MW-Node, the routing object lies before the address classifier. This is to enforce that data packets pass through the routing object. This is not the case with a standard MobileNode at the destination or at a portal (wired-wireless) node. Finally, a new network interface object is provided and enables: - per interface operation control (e.g. bring up/down one of two interfaces only) - better wired/wireless integration. Regards, Laurent Paquereau Q2S Centre of Excellence, NTNU Nguyen Lan wrote: Hello, I read your post on ns2 mailing list and I have a question what are the differences between your approach and Ramon's approach. Can you give me a suggestion in the case that I like to make a simulation with multi-interface in ns2: which approach is better or easier to implement. Cheers, Nguyen Laurent Paquereau wrote: Ramón, I have been reading your how-to and as your statements and concerns are quite similar to a subset of those we presented last year in [1], you might find interesting reading this paper. [1] Laurent Paquereau and Bjarne E. Helvik, A Module-based Wireless Node for ns-2, in Proceedings of the first Workshop on NS2: the IP network simulator (WNS2), Pisa, Italy, 2006. A Module-based Wireless Node (MW-Node) is a Node with wireless and mobile capabilities added by means of modules. It is not a new node object derived from Node. Rather it is a new layout of mostly existing components. The aim is to provide a flexible support for wireless and mobile networking and in particular: * support for multiple interfaces/multiple channels, and * a common basis for the implementation of wireless routing protocols. The code is distributed as a patch for ns-2.30 and is now available online with the documentation at: http://www.q2s.ntnu.no/~paquerea/ns.html Feedback and comments are much appreciated. Best regards, Laurent Paquereau Q2S Centre of Excellence, NTNU Ramon Aguero wrote: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems
Re: [ns] Multi-interface support howto, Ramon Submission
Hello,
Ok, I'm glad that you solved the problems related to the extension. I don't
really know how to address these warnings or whether they are relevant (at
least the virtual destructor one should not).
Cheers,
Ramón
At 13:25 13/02/2007, Nguyen Lan wrote:
Hello Ramon et al,
My problem is that I declared nIfaces, targetlist and ifqueuelist in the
aodv.h file but out of the class declaration. Now I can recompile ns but I
still had many many warnings like that
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:49: warning:
class TracedVar has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:87: warning:
class TracedInt has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:130: warning:
class TracedDouble has virtual functions but non-virtual destructor
common/scheduler.h:71: warning: class Handler has virtual functions but
non-virtual destructor
common/ip.cc: In member function virtual void
IPHeaderClass::export_offsets():
common/ip.cc:53: warning: invalid access to non-static data member
hdr_ip::src_ of NULL object
common/ip.cc:53: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:54: warning: invalid access to non-static data member
hdr_ip::dst_ of NULL object
common/ip.cc:54: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:55: warning: invalid access to non-static data member
hdr_ip::ttl_ of NULL object
common/ip.cc:55: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:56: warning: invalid access to non-static data member
hdr_ip::fid_ of NULL object
common/ip.cc:56: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:57: warning: invalid access to non-static data member
hdr_ip::prio_ of NULL object
common/ip.cc:57: warning: (perhaps the offsetof macro was used incorrectly)
Any idea about this is welcome.
Cheers,
Nguyen.
Nguyen Lan wrote:
Hello,
I have not declared them in common/packet.h. The only place I put them in
is aodv.h (as in the document). I think this problem came from other
place and I should read the document carefully but now I don't know yet.
Thank you very much.
Cheers,
Nguyen
Ramon Aguero wrote:
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in
common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error.
Maybe I was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of `targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that
the problem was that in the first version of the document we did not
highlight a couple of lines (the ones that you've modified); in the
original ns-mobilenode.tcl file, these two lines started with
$arptable_ **Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto, Ramon Submission
Hello Ramon et al,
My problem is that I declared nIfaces, targetlist and ifqueuelist in the
aodv.h file but out of the class declaration. Now I can recompile ns but
I still had many many warnings like that
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:49: warning:
‘class TracedVar’ has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:87: warning:
‘class TracedInt’ has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:130: warning:
‘class TracedDouble’ has virtual functions but non-virtual destructor
common/scheduler.h:71: warning: ‘class Handler’ has virtual functions
but non-virtual destructor
common/ip.cc: In member function ‘virtual void
IPHeaderClass::export_offsets()’:
common/ip.cc:53: warning: invalid access to non-static data member
‘hdr_ip::src_’ of NULL object
common/ip.cc:53: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
common/ip.cc:54: warning: invalid access to non-static data member
‘hdr_ip::dst_’ of NULL object
common/ip.cc:54: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
common/ip.cc:55: warning: invalid access to non-static data member
‘hdr_ip::ttl_’ of NULL object
common/ip.cc:55: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
common/ip.cc:56: warning: invalid access to non-static data member
‘hdr_ip::fid_’ of NULL object
common/ip.cc:56: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
common/ip.cc:57: warning: invalid access to non-static data member
‘hdr_ip::prio_’ of NULL object
common/ip.cc:57: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
Any idea about this is welcome.
Cheers,
Nguyen.
Nguyen Lan wrote:
Hello,
I have not declared them in common/packet.h. The only place I put them
in is aodv.h (as in the document). I think this problem came from
other place and I should read the document carefully but now I don't
know yet.
Thank you very much.
Cheers,
Nguyen
Ramon Aguero wrote:
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in
common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error.
Maybe I was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of
`targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly
fine.
I've sent an email previously, about the same changes. I think that
the problem was that in the first version of the document we did
not highlight a couple of lines (the ones that you've modified); in
the original ns-mobilenode.tcl file, these two lines started with
$arptable_ **Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the
$arptable variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto
hi ramon,
file: ns-mobilenode.tcl
function: Node/MobileNode instproc add-target-rtagent
here is a bigger part of the code (see the lines marked with ;#tim):
if { [Simulator set RouterTrace_] == ON } {
#
# Send Target
#
if {$newapi != } {;#
set sndT [$self mobility-trace Send RTR]
} else {
set sndT [cmu-trace Send RTR $self]
}
if { $namfp != } {;#
$sndT namattach $namfp
}
if { $newapi == ON } {
$agent target $imep_(0)
$imep_(0) sendtarget $sndT
# second tracer to see the actual
# types of tora packets before imep packs them
if { [info exists toraDebug_] $toraDebug_ == ON} {
set sndT2 [$self mobility-trace Send TRP]
$sndT2 target $imep_(0)
$agent target $sndT2
}
$sndT target [$self set ll_(0)]
} else { ;# no IMEP
;# multi channel, multi interface
if {$numIfsSimulator != } {;#
for {set i 0} {$i [$self set nifs_]} {incr i} {
#set sndT [cmu-trace Send RTR $self] ;#tim
set sndT [$self mobility-trace Send RTR] ;#tim
$sndT namattach $namfp ;#tim
$agent target $i $sndT
$sndT target [$self set ll_($i)]
}
} else {
$agent target $sndT
$sndT target [$self set ll_(0)]
}
}
cheers,
tim
Ramon Aguero schrieb:
Hi Tim,
I should have read this message before, sorry for the spam.
Can you clarify where did you add these two lines?
Cheers,
Ramón
At 10:49 09/02/2007, Tim Elschner wrote:
i got the wirless tracing back to business:
replaced:
set sndT [cmu-trace Send RTR $self] (see below)
with:
set sndT [$self mobility-trace Send RTR]
$sndT namattach $namfp
Tim Elschner schrieb:
i found out that a missing line in ns-mobilenode.tcl caused that
strange
behaviour.
since i correctly added
set sndT [cmu-trace Send RTR $self]
the traffic seems to be fine, except that the wireless packets don't
appear in NAM anymore.
-tim
Tim Elschner schrieb:
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to
associate
the interface.
in the forwardPacket function - which is for unicast
transmissions - i
use the information stored in the map to send the packets through the
correct interface. this works fine with interface 1, but fails vor
interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and
interface 0
fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't
think
you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct
procedure
-- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing
variable
arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have
been
sent to this list, it seems that a more thorough description
may be
required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within
the
different pieces of the simulator (tcl, c++) as well as how
routing
protocols can be adapted to make use of the new feature. The howto
is entitled Adding Multiple Interface Support in NS-2 and it has
been written by my colleague Jesús Pérez and myself.
I’ve uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to
improve
the howto, since we would like to
Re: [ns] Multi-interface support howto, Ramon Submission
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error. Maybe I
was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of `targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that the
problem was that in the first version of the document we did not
highlight a couple of lines (the ones that you've modified); in the
original ns-mobilenode.tcl file, these two lines started with $arptable_
**Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto
Hello Tim,
I've not personally used the NoAH extension myself, so I cannot completely
figure out which would be your problem.
Nevertheless, why do you use the prev_hop? I don't see the difference here
between NoAH and any other routing protocol. If you have received a message
from a base station via an interface, you might want to use that interface
to contact to the base station in the future. In this sense, I think that
you may want to get the interface index in the same way as it is explained
in the document (see Listing 4.6), and use that in the map.
Hope that this can help you.
Ramón
At 14:15 06/02/2007, Tim Elschner wrote:
hi,
i'm still stuck on transfering data via different channels using NOAH (NO
AdHoc Routing). maybe you can figure out if there is something wrong with
my approach.
i use only one mobile node, and some basestations with foreign agents, an
home agent and a corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function of NOAH - which is for unicast
transmissions - i use the information stored in the map to send the
packets through the correct interface. this works fine with interface 1,
but fails for interface 0. all packets are dropped. if i just flip the
channels between interface 0 and 1, still interface 1 is working and
interface 0 fails.
did i miss something?
thanks,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when copying
and pasting the code to the file.
The correct procedure would be the following one (note that the arptable_
is now within the 'for' cycle). In this sense, I don't think you need to
change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure --
in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences to
the original.
i got an error, that arptable_ is an array. so i changed every arptable_
into arptable. now ns2 complains about the missing variable arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the NS-2
framework to support multiple interfaces. Although there is some
information available, according to the messages that have been sent to
this list, it seems that a more thorough description may be required.
In this sense, after performing an analysis about existing activities
in this topic, we have created a document that tries to summarize which
are the required changes to be performed within the different pieces of
the simulator (tcl, c++) as well as how routing protocols can be
adapted to make use of the new feature. The howto is entitled Adding
Multiple Interface Support in NS-2 and it has been written by my
colleague Jesús Pérez and myself.
Ive uploaded the document, which can be retrieved from the following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
Hi Tim,
I should have read this message before, sorry for the spam.
Can you clarify where did you add these two lines?
Cheers,
Ramón
At 10:49 09/02/2007, Tim Elschner wrote:
i got the wirless tracing back to business:
replaced:
set sndT [cmu-trace Send RTR $self] (see below)
with:
set sndT [$self mobility-trace Send RTR]
$sndT namattach $namfp
Tim Elschner schrieb:
i found out that a missing line in ns-mobilenode.tcl caused that strange
behaviour.
since i correctly added
set sndT [cmu-trace Send RTR $self]
the traffic seems to be fine, except that the wireless packets don't
appear in NAM anymore.
-tim
Tim Elschner schrieb:
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function - which is for unicast transmissions - i
use the information stored in the map to send the packets through the
correct interface. this works fine with interface 1, but fails vor
interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and interface 0
fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't think
you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure
-- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing variable
arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have been
sent to this list, it seems that a more thorough description may be
required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within the
different pieces of the simulator (tcl, c++) as well as how routing
protocols can be adapted to make use of the new feature. The howto
is entitled Adding Multiple Interface Support in NS-2 and it has
been written by my colleague Jesús Pérez and myself.
Ive uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto, Ramon Submission
Hello,
I have not declared them in common/packet.h. The only place I put them
in is aodv.h (as in the document). I think this problem came from other
place and I should read the document carefully but now I don't know yet.
Thank you very much.
Cheers,
Nguyen
Ramon Aguero wrote:
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in
common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error.
Maybe I was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of
`targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that
the problem was that in the first version of the document we did not
highlight a couple of lines (the ones that you've modified); in the
original ns-mobilenode.tcl file, these two lines started with
$arptable_ **Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the
$arptable variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to
this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this
here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto
i got the wirless tracing back to business:
replaced:
set sndT [cmu-trace Send RTR $self] (see below)
with:
set sndT [$self mobility-trace Send RTR]
$sndT namattach $namfp
Tim Elschner schrieb:
i found out that a missing line in ns-mobilenode.tcl caused that strange
behaviour.
since i correctly added
set sndT [cmu-trace Send RTR $self]
the traffic seems to be fine, except that the wireless packets don't
appear in NAM anymore.
-tim
Tim Elschner schrieb:
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function - which is for unicast transmissions - i
use the information stored in the map to send the packets through the
correct interface. this works fine with interface 1, but fails vor
interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and interface 0
fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't think
you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure
-- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing variable
arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have been
sent to this list, it seems that a more thorough description may be
required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within the
different pieces of the simulator (tcl, c++) as well as how routing
protocols can be adapted to make use of the new feature. The howto
is entitled Adding Multiple Interface Support in NS-2 and it has
been written by my colleague Jesús Pérez and myself.
I’ve uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
i found out that a missing line in ns-mobilenode.tcl caused that strange
behaviour.
since i correctly added
set sndT [cmu-trace Send RTR $self]
the traffic seems to be fine, except that the wireless packets don't
appear in NAM anymore.
-tim
Tim Elschner schrieb:
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function - which is for unicast transmissions - i
use the information stored in the map to send the packets through the
correct interface. this works fine with interface 1, but fails vor
interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and interface 0
fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't think
you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure
-- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing variable
arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have been
sent to this list, it seems that a more thorough description may be
required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within the
different pieces of the simulator (tcl, c++) as well as how routing
protocols can be adapted to make use of the new feature. The howto
is entitled Adding Multiple Interface Support in NS-2 and it has
been written by my colleague Jesús Pérez and myself.
I’ve uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto, by Ramon Aguero
Hello Nguyen, (see inline) At 02:11 30/01/2007, Nguyen Lan wrote: Hi Razmon, I have a question related to the multi-interface support in ns2 - In Listing 4.4: hdr-iface() = addr(), addr is index of the interface that received this packet. But how can I get that value (which variant or function) The addr() method is declared in the Mac class and, since Mac802_11 inherits from this, you can use it. It will return the index_, which is somehow mapped to the mac address. - And in struct hdr_cmn (packet.h) there is a field name iface_ to store received interface index. Can I use it in Listing 4.4 like hdr-iface_ = xxx Well, basically the hdr-iface() method, just returns (in-line) the iface_ field (see definition of struct hdr_cmn in packet.h); so you are saying the same thing. Best regards, Nguyen Cheers, Ramón Ramon Aguero wrote: Hi Shahatha, As we say in the report we didn't use aodv, so we really appreciate that you work on this, it would be good trying to extend the report with your own experience on AODV. We have been doing a quick overlook of the aodv code (which we have not personally used that much) and this is what we can tell for the listings of chapter 5: - Listing 5.3 has to be used whenever the AODV needs to send a broadcast packet, which happens, as far as we can tell, in the following methods of the aodv.cc file: sendRequest, sendError, sendHello and forward; in this latter case only when the destination address is broadcast. In all of this, you should have the following command: Scheduler::instance().schedule(target_,pkt,*); --- * means either 0 or JITTER and you should change it for listing 5.3. - Listing 5.4 has to be used instead of the unicast transmissions of aodv.cc, this time in sendReply and forward methods. In this case, the Iface variable has to be the appropriate interface index, which needs to be stored within the corresponding route table entry (see section 5.3 of the document). - Listing 5.5 is the one that allows you to get the correct interface. When you have to create a route table entry, you need to indicate the corresponding index for the output interface, which will be used afterwards to send packets (see previous answer). This means that the corresponding struct/class for your route table entry needs to be updated, so as to be able to keep this index. Thanks to the changes of the mac-802_11.cc file (listing 4.6), the required value is store on the common header of the packet, that's the cmnh variable of the listing. Iface will just hold the index that will be used for creating/updating the route table entry. After a quick overlook of the code, this seems to be needed in two methods: recvRequest and recvReply. Cheers, Ramón At 10:53 18/01/2007, Shahatha wrote: Hello, did any one implement the extension of ns-2 for multi-channel from Ramon Aguero at: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr many thanks for Ramon Aguero for his Dokument. i have some problems at Chapter 5, where to add the listing 5.3 Listing 5.5 and Listing 5.6 in routingAgent.cc. (AODV.cc) i choice the AODV ad hoc routing agent to change. i think i can copy the Listing above 1 by 1 to the AODV.cc. thanks - NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
Re: [ns] Multi-interface support howto, Ramon Submission
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that the
problem was that in the first version of the document we did not highlight
a couple of lines (the ones that you've modified); in the original
ns-mobilenode.tcl file, these two lines started with $arptable_ **Note the
underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto, Ramon Submission
Hi Ramon and all,
After following the document when I recompile ns I got this error. Maybe
I was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of `targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that the
problem was that in the first version of the document we did not highlight
a couple of lines (the ones that you've modified); in the original
ns-mobilenode.tcl file, these two lines started with $arptable_ **Note the
underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
[ns] Multi-interface support howto
Ramón, I have been reading your how-to and as your statements and concerns are quite similar to a subset of those we presented last year in [1], you might find interesting reading this paper. [1] Laurent Paquereau and Bjarne E. Helvik, A Module-based Wireless Node for ns-2, in Proceedings of the first Workshop on NS2: the IP network simulator (WNS2), Pisa, Italy, 2006. A Module-based Wireless Node (MW-Node) is a Node with wireless and mobile capabilities added by means of modules. It is not a new node object derived from Node. Rather it is a new layout of mostly existing components. The aim is to provide a flexible support for wireless and mobile networking and in particular: * support for multiple interfaces/multiple channels, and * a common basis for the implementation of wireless routing protocols. The code is distributed as a patch for ns-2.30 and is now available online with the documentation at: http://www.q2s.ntnu.no/~paquerea/ns.html Feedback and comments are much appreciated. Best regards, Laurent Paquereau Q2S Centre of Excellence, NTNU Ramon Aguero wrote: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. I’ve uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN ramon at tlmat.unican.es Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function - which is for unicast transmissions - i
use the information stored in the map to send the packets through the
correct interface. this works fine with interface 1, but fails vor
interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and interface 0
fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't think
you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure
-- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing variable
arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have been
sent to this list, it seems that a more thorough description may be
required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within the
different pieces of the simulator (tcl, c++) as well as how routing
protocols can be adapted to make use of the new feature. The howto
is entitled Adding Multiple Interface Support in NS-2 and it has
been written by my colleague Jesús Pérez and myself.
I’ve uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
Hello, I already gave an answer regarding this (especially on Listings 5.3, 5.4 and 5.5. - Regarding Listing 5.1: you have to add that in the definition of the routing agent (i.e. the aodv.h file). - Regarding Listing 5.2: you have to modify the command method of the routing agent, which is within the aodv.cc file. HTH, Ramón At 10:06 21/01/2007, h sh wrote: Hello, Thank you very much for your Document. http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr As i understand i can extend one of the protocol agents: AODV, DSDV or TORA? i choice the AODV ad hoc routing agent to change. i have some problems at Chapter 5, In AODV.h i should add the Listing 5.1? In AODV.cc i should add the Listing 5.2, Listing 5.3, Listing 5.4 and Listing 5.5? Please help me Thanks Ramon Aguero [EMAIL PROTECTED] wrote: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
Re: [ns] Multi-interface support howto
Hi, The mail I was referring to, when I gave the is: http://mailman.isi.edu/pipermail/ns-users/2007-January/058433.html Cheers, Ramón At 12:00 29/01/2007, Ramon Aguero wrote: Hello, I already gave an answer regarding this (especially on Listings 5.3, 5.4 and 5.5. - Regarding Listing 5.1: you have to add that in the definition of the routing agent (i.e. the aodv.h file). - Regarding Listing 5.2: you have to modify the command method of the routing agent, which is within the aodv.cc file. HTH, Ramón At 10:06 21/01/2007, h sh wrote: Hello, Thank you very much for your Document. http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr As i understand i can extend one of the protocol agents: AODV, DSDV or TORA? i choice the AODV ad hoc routing agent to change. i have some problems at Chapter 5, In AODV.h i should add the Listing 5.1? In AODV.cc i should add the Listing 5.2, Listing 5.3, Listing 5.4 and Listing 5.5? Please help me Thanks Ramon Aguero [EMAIL PROTECTED] wrote: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
Re: [ns] Multi-interface support howto, by Ramon Aguero
Hi Razmon, I have a question related to the multi-interface support in ns2 - In Listing 4.4: hdr-iface() = addr(), addr is index of the interface that received this packet. But how can I get that value (which variant or function) - And in struct hdr_cmn (packet.h) there is a field name iface_ to store received interface index. Can I use it in Listing 4.4 like hdr-iface_ = xxx Best regards, Nguyen Ramon Aguero wrote: Hi Shahatha, As we say in the report we didn't use aodv, so we really appreciate that you work on this, it would be good trying to extend the report with your own experience on AODV. We have been doing a quick overlook of the aodv code (which we have not personally used that much) and this is what we can tell for the listings of chapter 5: - Listing 5.3 has to be used whenever the AODV needs to send a broadcast packet, which happens, as far as we can tell, in the following methods of the aodv.cc file: sendRequest, sendError, sendHello and forward; in this latter case only when the destination address is broadcast. In all of this, you should have the following command: Scheduler::instance().schedule(target_,pkt,*); --- * means either 0 or JITTER and you should change it for listing 5.3. - Listing 5.4 has to be used instead of the unicast transmissions of aodv.cc, this time in sendReply and forward methods. In this case, the Iface variable has to be the appropriate interface index, which needs to be stored within the corresponding route table entry (see section 5.3 of the document). - Listing 5.5 is the one that allows you to get the correct interface. When you have to create a route table entry, you need to indicate the corresponding index for the output interface, which will be used afterwards to send packets (see previous answer). This means that the corresponding struct/class for your route table entry needs to be updated, so as to be able to keep this index. Thanks to the changes of the mac-802_11.cc file (listing 4.6), the required value is store on the common header of the packet, that's the cmnh variable of the listing. Iface will just hold the index that will be used for creating/updating the route table entry. After a quick overlook of the code, this seems to be needed in two methods: recvRequest and recvReply. Cheers, Ramón At 10:53 18/01/2007, Shahatha wrote: Hello, did any one implement the extension of ns-2 for multi-channel from Ramon Aguero at: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr many thanks for Ramon Aguero for his Dokument. i have some problems at Chapter 5, where to add the listing 5.3 Listing 5.5 and Listing 5.6 in routingAgent.cc. (AODV.cc) i choice the AODV ad hoc routing agent to change. i think i can copy the Listing above 1 by 1 to the AODV.cc. thanks - NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
[ns] Multi-interface support howto, by Ramon Aguero
Hello, did any one implement the extension of ns-2 for multi-channel from Ramon Aguero at: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr many thanks for Ramon Aguero for his Dokument. i have some problems at Chapter 5, where to add the listing 5.3 Listing 5.5 and Listing 5.6 in routingAgent.cc. (AODV.cc) i choice the AODV ad hoc routing agent to change. i think i can copy the Listing above 1 by 1 to the AODV.cc. thanks - NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
Re: [ns] Multi-interface support howto
Hello Shahatha, In addition to the answers we have given before, see some more answers inline... Cheers, Ramón At 12:00 17/01/2007, you wrote: chapter 4 4.2 Listing 4.1 the variable MAX_CHANNELS i have declared it like a follow in mobilenode.h : #define MAX_CHANNELS XXX but which value? or without value? you do need to specify a value, depending on your own interests. This will set the maximum number of interfaces per node; i guess that realistically, having more than 8 would be difficult. 4.3 in channel.cc Listing 4.4: nextX_ and prevX_ should changed to nextX_ [this-index()] and prevX_ [this-index()] in the whole channel.cc. right? Yes, as stated in the document, just before the listing: Note that this has to be changed throughout the whole channel.cc file. - chapter 5 5.1 as i understand i can extend one of the protokol agents: AODV, DSDV or TORA, right? i have choice AODV. Good, probably we can extend the document with this experience. I'm not sure about TORA, since we have not seen that code at all. 5.2 MAX_IF should be declared in AODV.h with #define MAX_IF but which value? See my previous answer. in AODV.h the AODV-class i found ifqueue i chnage it to ifqueuelist[MAX_IF], and i found Trace *logtarget; but not target. i add targetlist[MAX_IF] just like in Listing 5.1. I won't delete ifqueue, since this is needed if you want to keep the legacy behaviour of the simulator. Keep the logtarget, since you need it for tracing support and add targetlist, as stated in Listing 5.1. in which mothod in AODV.cc i should add the Listing 5.3, Listing 5.4 and Listing 5.5 ? in Listing 5.5 Iface and cmnh are not declared ! All these questions have been already answered in my previous email. ps. do you have the changes as a dokument? No, since the main ns is being updated quite frequently and different people make different changes to the core files, we decided not make any code/patch available, but rather provide an extensive discussion of the required modifications, so that people can do it by themselves.
Re: [ns] Multi-interface support howto, by Ramon Aguero
Hi Shahatha, As we say in the report we didn't use aodv, so we really appreciate that you work on this, it would be good trying to extend the report with your own experience on AODV. We have been doing a quick overlook of the aodv code (which we have not personally used that much) and this is what we can tell for the listings of chapter 5: - Listing 5.3 has to be used whenever the AODV needs to send a broadcast packet, which happens, as far as we can tell, in the following methods of the aodv.cc file: sendRequest, sendError, sendHello and forward; in this latter case only when the destination address is broadcast. In all of this, you should have the following command: Scheduler::instance().schedule(target_,pkt,*); --- * means either 0 or JITTER and you should change it for listing 5.3. - Listing 5.4 has to be used instead of the unicast transmissions of aodv.cc, this time in sendReply and forward methods. In this case, the Iface variable has to be the appropriate interface index, which needs to be stored within the corresponding route table entry (see section 5.3 of the document). - Listing 5.5 is the one that allows you to get the correct interface. When you have to create a route table entry, you need to indicate the corresponding index for the output interface, which will be used afterwards to send packets (see previous answer). This means that the corresponding struct/class for your route table entry needs to be updated, so as to be able to keep this index. Thanks to the changes of the mac-802_11.cc file (listing 4.6), the required value is store on the common header of the packet, that's the cmnh variable of the listing. Iface will just hold the index that will be used for creating/updating the route table entry. After a quick overlook of the code, this seems to be needed in two methods: recvRequest and recvReply. Cheers, Ramón At 10:53 18/01/2007, Shahatha wrote: Hello, did any one implement the extension of ns-2 for multi-channel from Ramon Aguero at: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr many thanks for Ramon Aguero for his Dokument. i have some problems at Chapter 5, where to add the listing 5.3 Listing 5.5 and Listing 5.6 in routingAgent.cc. (AODV.cc) i choice the AODV ad hoc routing agent to change. i think i can copy the Listing above 1 by 1 to the AODV.cc. thanks - NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
Re: [ns] Multi-interface support howto
great job as far as i can see. anyway i ran into problems with ns-mobilenode.tcl: in Node/MobileNode instproc reset i couldn't find any differences to the original. i got an error, that arptable_ is an array. so i changed every arptable_ into arptable. now ns2 complains about the missing variable arptable :( any hints out there? cheers, tim Ramon Aguero schrieb: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. I’ve uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when copying and
pasting the code to the file.
The correct procedure would be the following one (note that the arptable_
is now within the 'for' cycle). In this sense, I don't think you need to
change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure -- in
the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences to the
original.
i got an error, that arptable_ is an array. so i changed every arptable_
into arptable. now ns2 complains about the missing variable arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the NS-2
framework to support multiple interfaces. Although there is some
information available, according to the messages that have been sent to
this list, it seems that a more thorough description may be required.
In this sense, after performing an analysis about existing activities in
this topic, we have created a document that tries to summarize which are
the required changes to be performed within the different pieces of the
simulator (tcl, c++) as well as how routing protocols can be adapted to
make use of the new feature. The howto is entitled Adding Multiple
Interface Support in NS-2 and it has been written by my colleague Jesús
Pérez and myself.
Ive uploaded the document, which can be retrieved from the following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve the
howto, since we would like to have it like a living document, adding new
features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
Hi ramon Thanks for this great contribution. This is exactly the kind of useful documentation contributions that the NS2 simulator community needs. Pedro Vale Estrela -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ramon Aguero Sent: segunda-feira, 15 de Janeiro de 2007 10:12 To: ns-users@ISI.EDU Cc: [EMAIL PROTECTED] Subject: [ns] Multi-interface support howto Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488
[ns] Multi-interface support howto
Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488
