From nsnam
Revision as of 17:08, 12 February 2010 by Tomh (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Main Page - Roadmap - User Information - Developer Information - Projects - Contributing - Links

The ns-2 set of software packages (ns-2, nam-1, OTcl, TclCL) is a lightly supported open source project. For help with ns-2, the best way to get help is to first search the Internet, and old ns-users postings for the answer to your question before posting to the ns-users mailing list. Please see below for information about the mailing lists, and how to report bugs. You are also encouraged to help by contributing to this wiki.

General problems

See this web page (note, some information is out of date).

Installation troubleshooting

ns-allinone package

Note: you may also want to consider tips under the entries for the individual packages below, to see if your allinone installation problem is found there.

Installation of ns-2.29.2 fails on x86_64 platform

  • Description: otcl-1.11 compilation fails in the following way:
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/ when
> searching for -lXext
> /usr/bin/ld: cannot find -lXext
> collect2: ld returned 1 exit status
> make: *** [otclsh] Error 1
> otcl-1.11 make failed! Exiting ...
  • Previous solution: Find the path to the 64-bit libraries and modify the makefile (e.g., /usr/X11R6/lib64)
  • New solution: Use the ns-allinone-2.29.3.tar.gz package.

Precompiled NS2-2.34 binaries for OS X Leopard 10.5 / Snow Leopard 10.6

You can download my precompiled package of ns2 for Snow Leopard / Leopard at the following address:

(11/11/2009) - Support for NAM is now fully enabled.

OS X Leopard 10.5

Lloyd Wood notes:

>I'm trying to install octcl 1.1.3 on Mac OS X 10.5.2, as part of the ns 2.32 allinone install:

  checking for X11 header files
  checking for X11 library archive
  checking for XOpenDisplay in -lX11... no
  can't find X library

Thanks to gier egeland and David Viera for the hints.

 ./configure --x-includes=/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include \\

worked for me to successfully configure and make otcl-1.13, tclcl-1.19, and ns-2.32 on Leopard.

That also worked for configuring nam-1.13, but that failed at the linker stage bleating

  Undefined symbols:
  __TkCreateXEventSource", referenced from:
   _TkpInit in tkUnixInit.o

so I grabbed nam-1-20080222.tar, which failed with the same linker error.

(I was using the available Tcl/Tk in the system, but using the allinone compiled Tcl/Tk made no difference here.)

I expect that the above will work for any Mac OS X 10.4 or 10.5 with XCode with the added X11 headers -there's a pkg on Leopard Install disc 1. The parallel MacOSX10.5.sdk/ tree is pretty empty, relying heavily on the base code in 10.4u (for universal: on Intel and PowerPC). On 10.3, using directories under /Developer/MacOSX10.3.9.sdk/ *may* well work - that directory exists, but the tree under it is mostly empty under Leopard.


ns-2 not building with gcc/g++ 4.3.2

  • Description: the screen is filled with warnings such as:
 ./common/packet.h:358: warning: deprecated conversion from string constant to ‘char*’
  • Solution: Add this flag "-Wno-write-strings" to the CCOPT line in the Makefile; e.g.:
 CCOPT   = -g -Wall -Wno-write-strings 

ns-2.30/ns-2.31 do not build with gcc/g++ 4.1

  • Description: Linking stage fails with error:
/usr/bin/ld: ns: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
  • Solution: Apply the following patch to in otcl-1.12 or otcl-1.13:
diff -uNr otcl-1.12/ otcl-1.12-patched/
--- otcl-1.12/	2006-09-25 01:02:37.000000000 -0400
+++ otcl-1.12-patched/	2007-04-12 11:45:09.000000000 -0400
@@ -74,7 +74,7 @@
-        SHLIB_LD="ld -shared"
+        SHLIB_LD="${CC} -shared"

then rebuild the OTcl configure script:

otcl-1.13$ autoconf -f

You should now be able to build OTcl (and everything else) normally. Thanks go to Chia-Yung Su for figuring this out and for providing a reference to a similar problem in a different program.

  • Alternative: To work around the problem, install gcc-4.0 and g++-4.0 and use them to compile OTcl:
otcl-1.13$ ./configure CC="gcc-4.0" CXX="g++-4.0" --with-tcl=../tcl8.4.14 --with-tk=../tk8.4.14

You can also use gcc-4.0 and g++-4.0 to compile everything. This may be simpler than using 4.0 for just OTcl (as suggested above). Type the following before you start building the programs:

export CC="gcc-4.0"
export CXX="g++-4.0"


if previous tips dont work and after the tric, do the following (source : [1]). It solves the issue on edgy with

gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

  • for otcl use ./configure then manualy edit Makefile:8
- CFLAGS=		-g -O2 
+ CFLAGS=		-g -O2 -fno-stack-protector
  • for ns nam use ./configure then manualy edit Makefile:82
+ CFLAGS	+= $(CCOPT) $(DEFINE) -fno-stack-protector

ns-2.29 does not compile on Fedora Core 5 (FC5)

  • Description: ns-2.29 release does not compile on FC5
  • Old solution: This patch contributed by Qihe Wang:
  • New solution: Use the ns-allinone-2.29.3.tar.gz package if you just want to use ns-2.29 release; if you want to use current cvs snapshot, apply Qihe Wang's patch to that.


  • Description: You've installed ns and run an example script, and get this error:
ns: finish:couldn't excute "nam":no such file or directory
    while excuting
"exec nam out.nam &"
    (procedure "finish" line 7)
     invoked from within
  • Solution: This indicates that you have not installed nam or the nam binary is not being found by the script. Perhaps you need to add the path to the binary. Make sure you have added the path to the nam binary to your shell variable $PATH (I am presuming you are using Linux and bash as you didn't specify) using the following: export $PATH="$PATH:/path/to/nam/binary". Note : this will have to be done every time you start a new terminal as it only lasts as long as that particular session. To make it permanent, you will have to enter this line into either your .bashrc or .bash_profile (or similar). (Thanks to Matthew Jakeman for this note)

nam-1.12 does not compile on 64-bit platforms

The current cvs directory (as of November 19 or later) contains code that will build on 64-bit machines, but you may need to edit the Makefile (change "lib" to "lib64" directories) since the autoconf code is not working just yet. Here is a link to the daily snapshot of nam-1:

Post-install troubleshooting

ns-2 builds but fails some validation tests

  • Description: ns-2 fails some validation tests
  • Solution: ns-2 is known to have problems with some validation tests on certain platforms due to 64-bit problems or floating point differences on different platforms. If the particular validation test is not central to your work, the error may be safely ignored. Please consider reporting a bug if you find new validation problems.

unexpected behavior or crash (segfault) after code extension

In order to determine why ns-2 does not work as you expect or or why it crashes, you have to use a debugger like gdb to figure out what happened.

If you have never worked with a debugger before, it might look a little bit difficult at first but it's an absolute necessity for any serious programmer to master it. People on the mailing list won't be willing to help you unless you have not tried seriously to fix the problem yourself.

To get you started, there are some excellent tutorials on the Internet for both gdb (like [2], [3]) and ddd, a GUI to gdb (PDF slideshow). Install either of them, make sure you have enabled debugging symbols in ns-2 (see the relevant part in the user tips), and re-compile everything. Afterwards, start ns through the debugger, pass your tcl-script as argument using set args <path to script> and either choose a reasonable breakpoint or let ns-2 crash and watch the backtrace, depending on whether after adding your code the simulator just does not work appropriately or crashes, respectively. When you managed to narrow down the responsible piece of code, use the debugger's capabilities to investigate even further (print, watchpoints, change variable values, etc.) in order to fix the bug(s).

What makes things a little more complicated is the fact that ns-2 not only uses C++ but OTcl as well. When the simulator crashes and leaves you with an OTcl backtrace, try to figure out what happened by watching at that. If that does not suffices and there is no valuable C++ backtrace, take a look at the ns-2 debugging page to learn how to include and use the Tcl debugger. Since it's not as sophisticated as gdb, you might want to consider setting debug 1 at different points within the Tcl simulation script first and see from what point on it crashes. Apart from that, the page tells you how to determine a node's (string) name from C++, jump into Tcl space and use the tcl debugger from there before possibly returning to C++ space.

If you require further help on debugging, please consider some of the links under Other tips from users: Pedro Vale Estrela has provided some additional hints and tools, particularly useful with OTcl.

You could also check the sections on Debugging ns-2.

Bug Reporting

Other tips from users

  • How to compile NS2 with debugging information/How to use DDD for debugging NS2:: Email thread

when and how to write to the user's mailing-list

If you think you need to ask people on the mailing-list, please consider the following prior to submitting:

  1. VERY IMPORTANT: in general, have you tried hard enough to solve problems you encounter yourself? This includes (and goes beyond) reading anything possibly related to your problems as covered in the ns-2 manual, this wiki and the ns-2 webpage
  2. if ns-2 ceased to work properly after you made some changes, please
    • read the wiki part about debugging first
    • get a book on C++/Tcl and/or search the web to solve common progamming language problems
  3. search the mailing-list archives exhaustingly (this is mandatory!)
  4. consider this very good advice in asking and receiving help: How To Ask Questions The Smart Way, particularly:
  5. for compiling issues:
    • include compiler errors in English language using LC_ALL=C make
    • include complete error messages on the relevant parts (don't truncate line numbers!)
    • include part of code which errors relate to

Some problems when using ns-2


How to callback to OTcl from C++ code

  For example, In OTcl, you have the object named: object(i) and simulator object named: ns

  In C++ you should use as follows:
  Tcl::instance().evalf( "$object(%d) operation %d %d %d %d", src, src, des, master, object);
  You also can add when to execute this operation:
  Tcl::instance().evalf( "$ns [$ns now] $object(%d) operation %d %d %d %d", src, src, des, 
  master, object);


How to use procedure in OTcl

 set ns        [new Simulator]
 global ns  tcp app
 for {set j 0} {$j < 13} {incr j} {
 	set tcp($j) [new Agent/TCP/SimpleTcp]
 set app(0) [new Application/TcpApp $tcp(0) source 0]
 for {set k 1} {$k < 13} {incr k} {
   set app($k) [new Application/TcpApp $tcp($k) common $k] }
 proc doLETJOIN {src des master object} {
   global ns tcp app ;# this is essential!!!
   $ns at [$ns now] "$ns connect $tcp($src) $tcp($des)"
   $ns at [$ns now] "$tcp($src) listen"
   $ns at [$ns now] "$tcp($des) listen"
   $ns at [$ns now] "$app($src) connect $app($des)"
   $ns at [$ns now] "$$src letjoin $src $des $master"
 proc my_test {} {
 	global ns
 	puts "inside test"
 	doLETJOIN 0 1 0 4
 $ns at "1" "my_test"
 $ns run

Older versions of ns-2, nam-1, tclcl, and otcl

This wiki page started maintaining troubleshooting information as of the releases of the following packages:

  • ns-2.29
  • nam-1.11
  • otcl-1.11
  • tclcl-1.17
  • ns-allinone-2.29.2

For troubleshooting older versions of these packages, please see the following page: