Hello, In this section we will discuss about installation problems and possible fixes for them between releases. In general, these are fixes for ns/otcl/tclcl installation problems.
If you experience problem when building a ns daily snapshot, you probably want to update your otcl and tclcl to the most current snapshot as well. Sometimes changes in ns will require an updated tclcl. If you are using nam with ns snapshot, it is recommended that you update nam together with ns because ns may provide new visualization features which requires an updated nam.
- Problem: I can't download ns from your web site.
Work-arounds: First, many people have successfully downloaded ns (unless you're the first person to get a brand new release!). Odds are that the solution to problems downloading lie on your end: make sure that your browser isn't compressing or uncompressing it for you; try Netscape if you're using IE, or try another program to download like GNU wget; make sure you use (GNU) gunzip to uncompress it, not PKZIP.
If these tricks don't help, you might also try getting it via FTP (from ftp://ftp.isi.edu/nsnam) instead of HTTP (from http://www.isi.edu/nsnam/dist). If ftp'ing, try using a dedicated FTP client instead of a web browser, and make sure you transfer in BINARY mode, not TEXT.
- Problem: I can't subscribe or unsubscribe to the mailing list. I get error messages back like:
>>>>> This is a multi-part message in MIME format.
>**** Command 'this' not recognized.
>>>>>
>>>>> ------=_NextPart_000_0013_01C00841.7A1B9BA0
>END OF COMMANDS
Solution: Send simple text (ASCII) e-mail to the subscribe address, not MIME. Majordomo, the mailing list management program we use, can't handle MIME.
- Problem: My posts to the mailing list are rejected. I'm even subscribed to it.
Solution: Please see the mailing-list FAQ.
- Problem: I was successful in installation, but I can't run the example script in in tutorial simple.tcl. When i tried to run it gives few errors like:
use-scheduler: command not found
attach-node: command not found
...
Solution: you need to run the script by issuing command: ns simple.tcl and you should add ns' directory to the environment variable PATH.
- Problem: Ok, but I still can't run simple.tcl under the ~ns/tcl/ex directory, it gives an error saying:
couldnt execute nam:
no such file or directory while executing "exec nam out.nam &".
(Also, when I try typing the comamnd "ns simple.tcl", and I get the error "ns: command not found".)Solution: Well, you need to add nam' directory to the environment variable PATH or specify its location in the tcl script. (PATH is part of Unix, so if you're not sure how it works, please consult a local Unix expert or search the web on "unix PATH".)
- Problem: To fix another problem it says to "apply a patch file". What's that? How do I do that?
Solution: To apply a patch file, get the the "patch" program (it ships with Linux and FreeBSD, or you can get it from ftp.gnu.org. Change into the directory with the source code you want to patch and type "patch < /path/to/patch-file.patch". See the patch(1) man page for details about what messages you'll see.
Bonus answer: how to generate a patch file. To generate a patch file, use the "diff" program with the "-u" or "-c" option: "diff -u old-copy-of-file.cc file.cc". (This requires that you have saved a copy of the file before you modified it.)
- Problem: I tried to apply a patch, but it failed. For example, I got messages like:
[root@srn04 ns-2.27]# patch < newfi.patch
patching file Makefile.in
Hunk #1 FAILED at 25.
1 out of 1 hunk FAILED -- saving rejects to file
Makefile.in.rej
patching file Makefile.in
Solution: Patches will succeed when applied to the same version of code against which they were generated. If the code has changed, you will get error messages like "hunk failed".
Unfortunately, there is no general solution to failed patches. It could be that the underlying code changed so much the old patch will not work. But it could be that there were minor changes to the basic code and you could apply the patch manually.
Some hints if you want to try manually applying a patch: If you want to try applying a patch by hand, you need to understand what you're patching, more or less. If you're trying to patch a Makefile and you have no idea what a makefile is, it's very possible you'll make an accidental error that prevents things from working. But don't fear, you can at least try, and you can always read the documentation about the make program and learn something! In the worst case you have to undo what you did. Also, although you will need some clue about what you're doing, you probably don't have to completely understand the code. If you try to manually apply a patch, you should study the patch manual page so you can understand the simple format that a patch file and a .rej file use.
If you're not willing or able to manually apply a patch, you have one other alternative. A patch file takes original code (call it X-orig) and changes it into new code (call it X-new) by applying the differences described in the patch. Patches fail if the patch program cannot find what's described in the patch in X-orig. So an alternative to manually applying the patch is to find different original code. If you find the same original code the person who made the patch used, you should get it to apply cleanly. So, for example, if a patch was generated against ns-2.26 and it fails when applied to ns-2.27, you could get rid of your copy of ns-2.27 and go get ns-2.26, then apply the patch to that older version. (Of course, this approach has other problems, since you may want other things that are only in ns-2.27. TANSTAAFL.)
- Problem: When I run validate or one of the test suites, I get these messages: warning: using backward compatibility mode and using backward compatible Agent/CBR; use Application/Traffic/CBR instead. Is my simulator broken?
Solution: No, ns is not broken. These are warning messages output by the test suites, not errors. (However, if you get these messages from your scripts, we encourage you to move to the newer APIs.)
- Problem: I got the following error message during building OTcl
creating cache ./config.cache
No .configure file found in current directory
Continuing with default options...
checking host system type... alpha-dec-osf4.0
checking target system type... alpha-dec-osf4.0
checking build system type... alpha-dec-osf4.0
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for c++... c++
checking whether the C++ compiler (c++ ) works... no
configure: error: installation or configuration problem: C++ compiler
cannot create executables.
Solution: Your c++ compiler (with exact name c++) does not seem to work. Check with your sytem admin.
- Problem: I get linking errors when building ns or nam like
Undefined first referenced
symbol in file
et_tclobject
/space/opt/ns-allinone-2.1b6/tclcl-1.0b9/libtclcl.a(Tcl.o)
ld: fatal: Symbol referencing errors. No output written to ns
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `ns'
(or other symbols that begin with et_*).Solution: Build everything with gcc, don't mix gcc/g++ and cc/ld. (Insure that if you build any C++ code with g++ that you link with g++, and that they're the same version.)
(These very confusing errors are from gcc. "et" is part of the run-time type checking. This code is generated at load time; gcc gets confused if you mix compilers.)
- Problem: I get errors like this when building ns-allinone:
[root@localhost unix]# make
gcc -pipe -c -O2 -Wall -Wno-implicit-int -fno-strict-aliasing -fPIC -I/home/vahid/Desktop/Temp/tk8.4.7/unix -I/home/vahid/Desktop/Temp/tk8.4.7/unix/../generic -I/home/vahid/Desktop/Temp/tk8.4.7/unix/../bitmaps -I/home/vahid/Desktop/Temp/tcl8.4.7/generic -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DPEEK_XCLOSEIM=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -DTCL_NO_DEPRECATED -DUSE_TCL_STUBS /home/vahid/Desktop/Temp/tk8.4.7/unix/../generic/tk3d.c
In file included from /home/vahid/Desktop/Temp/tk8.4.7/generic/tkInt.h:21,
from /home/vahid/Desktop/Temp/tk8.4.7/generic/tk3d.h:18,
from /home/vahid/Desktop/Temp/tk8.4.7/generic/tk3d.c:16:
/home/vahid/Desktop/Temp/tk8.4.7/generic/tk.h:96:29: X11/Xlib.h: No such file or directory
In file included from /home/vahid/Desktop/Temp/tk8.4.7/generic/tkInt.h:21,
from /home/vahid/Desktop/Temp/tk8.4.7/generic/tk3d.h:18,
from /home/vahid/Desktop/Temp/tk8.4.7/generic/tk3d.c:16:
/home/vahid/Desktop/Temp/tk8.4.7/generic/tk.h:573: parse error before "Window"
...
Solution: You don't have the development libraries for X11 installed on your system (see "X11/Xlib.h: No such file or directory").
Fix: install the X11 development libraries. How you do this is system-specific. In Redhat-like Linux distributions, make sure you have the X11 -devel packages installed. (In Fedora Core 2, installing xorg-x11-devel will fix this specific problem; in general you may need other -devel packages for libc, X11, and Tcl.)
- Problem: Validation under Windows does not work.
Solution: As of ns 2.26, the windows port uses Cygwin which should substantly reduce validation errors. Please have a look at individual ns versions for specific details. The following information is way outdated.
First, you need to download Cygwin, as of 2000-06-22 at version 1.1.2, which provides GNU binary utilities for the Windows platforms. You may also want to download pre-compiled Perl for Windows. After you've got all these tools, apply the following patch to ~ns/tcl/test/test-all-template1 to get around the \r\n problem:
*** test-all-template1.orig Wed Jan 5 01:01:00 2000
--- test-all-template1 Thu Jun 22 16:04:10 2000
***************
*** 117,123 ****
cp $datafile.bk $datafile
mv $datafile.Z $directory/$t.Z
else
! gzip -dc $directory/$t.Z | cmp -s - $datafile
if [ $? = 0 ]; then
echo Test output agrees with reference output
else
--- 117,123 ----
cp $datafile.bk $datafile
mv $datafile.Z $directory/$t.Z
else
! gzip -dc $directory/$t.Z | perl -ne 'print $_;' |cmp -s - $datafile
if [ $? = 0 ]; then
echo Test output agrees with reference output
else
NOTE: Some of the test suites will fail on win32 platform. As of Feburary 26, 1999 snapshot of ns, the following test suites fail: ./test-all-simple ./test-all-tcp ./test-all-red ./test-all-sack
./test-all-schedule ./test-all-red-v1 ./test-all-sack-v1 ./test-all-v1
./test-all-vegas-v1 ./test-all-ecn ./test-all-manual-routing
./test-all-intserv ./test-all-webcache ./test-all-srm
However, all of them failed because of floating point rounding differences on win32 and on unix. We will test current ns snapshots and update the results here. Thanks to Christian Joensson for his enthusiasm in keeping providing the information and patches for many ns releases.IMPORTANT NOTE: The cygwin release 1.3.2 currently available (as of 07/2001), which we installed in win2000, doesn't seem to have a functional awk utility. A significant portion of the ns validation script uses awk, so we tried to replace awk with perl; but now the bash shell (another cygwin utility) didnot handle stdin/stdout correctly. So we were unable to validate the windows version (ns2.1b8a) in this platform. We welcome any suggestion from windows users to help solve this problem.
- Problem: The test suites and validation fail with errors like
ns: _o3 cleanup file5 sackB4: Syntax error in file ../../bin/raw2xg at
line 43, next 2 tokens "my("
Syntax error in file ../../bin/raw2xg at line 59, next 2 tokens
"translate_point("
Syntax error in file ../../bin/raw2xg at line 94, next 2 tokens
"translate_point("
Execution of ../../bin/raw2xg aborted due to compilation errors.
Can't locate 5.0010000000000003 in @INC at ../../bin/getrc line 4.
while executing
(where the key parts are "syntax error near my(" and "can't locate 5.001").Solution: Get perl5 and/or make sure the programs in ~ns/bin are invoking perl5.
Ns's configure checks for perl5, but apparently this check is not sufficient for many people's systems. Suggestions for improving the check are encouraged (it already works on our systems).
- Problem: Things built OK but don't run because of missing shared libraries (for example, you get the message "can't load library 'libotcl.so'" or "fatal: libotcl.so: can't open file: errno=2" [from Solaris]) or "libotcl.so can not open shared object file: No such file or directory".
Solution: Many systems require that you do something special when installing new shared libraries. Shared-library loading is system-dependent, so consult the man page for ld(1) on your system. On many systems the program ``ldd'' can be used to diagnose shared-libary problems.
A couple of hints: many systems require that you set the environment LD_LIBRARY_PATH to specify where to look for shared libraries. So if (let's say), you get the above error with otcl shared library (libotcl.so), you should append the path to your libotcl.so (which typically would be in the directory you have installed and built otcl) to the LD_LIBRARY_PATH macro in your .cshrc file. Other systems require that you run ldconfig when using new libraries.
- Problem: Ns (or otcl or tclcl) gets link errors when building with references to "dlopen" similar functions beginning with dl.
Work-around: You need to manually add the library for dynamic linking to ns's Makefile. Look in the Makefile for the line LIB= and add your systems library for dynamic linking (typically -ldl).
Solution: Unfortunately ns's autoconf support for dynamic linking isn't currently very good, and we can't test ns on all the platforms on which it's used. This configuration is done in ~ns/conf/configure.in.dynamic. If you can adjust the code there to correctly detect your system we'll be happy to add your patch to our sources.
- Problem:While building ns, it gets compiled but bails out with the following error message during linking:
c++ -static -o ns \
tclAppInit.o random.o rng.o ranvar.o misc.o
....
....
-lXext -lX11 -lsocket -lnsl -ldl -lm
ld: fatal: library -ldl: not found
ld: fatal: File processing errors. No output written to ns
*** Error code 1
make: Fatal error: Command failed for target `ns'
Solution:This error appears due to compiling with the static flag on. In static mode, ld selects only the shared object and archive files ending with .a, (unlike dynamic mode where files ending with either .so or .a are acceptable).
Thus you will need to either
- configure with static option explicitly turned off with --disable-static, or
- edit ns makefile to replace the value "static" for the macro STATIC with blank (Dynamic mode is the default option).
- Problem: Ns is running out of memory and segfaulting.
Solution: See the memory debugging tips section of the debugigng tips web page.
- Problem: I want to simulate ATM networks in ns. What should I do?
Solution: If you just want to treat ATM as a 155Mb/s link for IP packets, you can get a pretty good approximation by, well, making a 155Mb/s link. Or a better approximation by accounting for ATM framing and using a 135Mb/s link.
If you actually want to explore the interaction between ATM cells and IP packets, or MPLS, or something like that, you may have to implement it yourself or pack up a third-party package.
One user (thanks L.) suggested in ns-users:
http://freebsd1.lums.edu.pk/~umair/NS/doc/index.html (there's a mirror at: http://www.ee.surrey.ac.uk/Personal/L.Wood/ns/ATM/ if you can't reach that.)
It's for ns version 1, it's third-party, it's unsupported, you're on your own.
Deriving an ATM node class for ns-2 would actually be one of the few cases where you'd expect incompatibilities between the derived class and everything else, and where the rest of the things ns simulates are _supposed_ to fail badly across it... would make it easier to implement; less testing required!
- Problem: How do I properly reference the ns-2 simulatorin my papers ?.
Solution:
There are two answers to that question.
If you want to cite the software itself, you can cite:
S. McCanne and S. Floyd. ns Network
Simulator. http://www.isi.edu/nsnam/ns/.
and/or the manual:
Kevin Fall, Kannan Varadhan, and the VINT project.
The ns manual.
If you want something published in a refereed location,
[Breslau00a]
Lee Breslau, Deborah Estrin, Kevin Fall, Sally Floyd, John Heidemann, Ahmed
Helmy, Polly Huang, Steven McCanne, Kannan Varadhan, Ya Xu, and Haobo Yu.
Advances in Network Simulation.
_IEEE Computer_, V. 33 (N. 5 ), pp. 59-67, May, 2000.
Expanded version available as USC TR 99-702b
at \urlhttp://www.isi.edu/ johnh/PAPERS/Bajaj99a.html.
.
- Problem: What should I do if the ns executable has its modification time in the future when I re-start my machine after shutdown?
Solution: We recommend that you talk to your local sysadmin since this indicates a clock difference between the file server and the client (this has nothing to do with ns).
- Problem: When using nam I get the following error: no display name and no $DISPLAY"
Solution: Start the X server using startx at the prompt. Set the display environment variable using setenv DISPLAY my_hostname:0.0 (if you are using cshrc) or export DISPLAY=my_hostname:0.0 (if you are using sh or bash). This solution works for both cygwin and unix.
- Problem: Some ns-2.1b6 test suites don't pass (test-all-monitor, etc.) when ns is built with tcl-8.3.
Solution: Two choices: (1) get tcl-8.0.3. (2) update to a snapshot of ns-2 and tclcl after 17 August 2000. For additional details see this message to ns-users.
- Problem: ns crashes (segfaults) with Tcl_ParseCommand() at the top of the traceback, or test-all-vc or test-all-monitor fail.
One cause for this is that Tcl_Eval was called on a read-only string. (Tcl_ParseCommand changes strings in-place in tcltk-8.3.) This is a problem in some systems where the C compiler makes string constants read-only.
Here's the top of the traceback from test-all-monitor:
#0 0x4012f1d7 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so
#1 0x40130228 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so
#2 0x4012ff5e in Tcl_EvalTokens () from /usr/lib/libtcl8.3.so
#3 0x401302a2 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so
#4 0x40130541 in Tcl_Eval () from /usr/lib/libtcl8.3.so
#5 0x400fa063 in Tcl_GlobalEval () from /usr/lib/libtcl8.3.so
#6 0x8114c97 in Tcl::eval () at gen/ptypes.cc:297
#7 0x805eb87 in Agent::trace (this=0x83df338, v=0x83df57c)
at agent.cc:282
#8 0x8063f90 in TcpAgent::trace (this=0x83df338, v=0x83df57c)
at tcp.cc:320
#9 0x81161e9 in TclObject::handle_TracedVar () at gen/ptypes.cc:297
#10 0x811671f in TclObject::delay_bind () at gen/ptypes.cc:297
#11 0x8063412 in TcpAgent::delay_bind_dispatch (this=0x83df338,
varName=0x83dd4c8 "cwnd_", localName=0x83dd4c8 "cwnd_",
tracer=0x83df338) at tcp.cc:231
This problem has been observed on Linux systems running RedHat 7.0 (i.e., tclcl-8.3 and gcc 2.96). Probably it appeared there because either tclcl-8.3 changed Tcl_ParseCommand or gcc 2.96 changed string constants to be read-only by default.
Solution: Update to a tclcl snapshot after 17 August 2000 (or the 1.0b10 release, whenever that happens).
Other work-arounds: change your compiler to make string constants writable (in gcc, add "-fwritable-strings" to CFLAGS and LDFLAGS).
- Problem: Configure of otcl, tcl or ns fails with the message "cannot run test program while cross-compiling".
telesto{ddutta}8: ./install
creating cache ./config.cache
checking for ranlib... ranlib
checking whether cross-compiling... yes
checking for getcwd... no
checking for opendir... no
...
checking for -linet... no
checking for net/errno.h... yes
checking whether char is unsigned... configure: error: can not run test
program while cross compiling
tcl8.0.4 configuration failed! Exiting ...
Solution: This error happens on Solaris systems where gcc is installed and Sun's C compiler is not installed, but configure decides to use Sun's compiler anyway.
As a work-around, set the environment variable "CC" to "gcc" and "CXX" to "g++" (setenv CC gcc; setenv CXX g++;) before configuring ns.
In the next release of ns it will prefer gcc to cc when both ar available, hopefully fixing this problem.
- Problem: invalid command name "Mac/Csma/Cd"
Solution: use the Mac/802_3 agent which implements CSMA/CD to replace Mac/Csma/Cd
- Problem: Running validation on RedHat Linux 6.0 with egcs-2.91.66 reports the following test suites as broken:
./test-all-cbq ./test-all-cbq-v1 ./test-all-webcache ./test-all-wireless-lan
./test-all-wireless-gridkeeper ./test-all-wireless-lan-newnode ./test-all-wireless-lan-tora
Solution: Remove -O2 optimization from the makefile and recompile everything. Alternatively, you can configure everything with debugging enabled, which doesn't pass -O2 option to the compiler. Just do:
make clean
./configure --enable-debug
make
- Problem: When running a simultation, I get the error
ns: scheduler going backwards in time from X to Y.
Solution: Have you modified anything in NS code? I've had this problem becouse of incorrect calls to Scheduler::schedule. If something schedule an event with a time already gone (less than current time of the scheduler), the Scheduler::dispatch will generate that message. I've solved my problems debugging with a breakpoint in scheduler.cc line 99 ( fprintf(stderr, "ns: scheduler going backwards in time from %f to %f.\n", clock_, t); ), and than with backtrace to find the incorrect scheduling. [Contributed by Massimo Pegorer]
Here is also a relevant excerpt from a message appeared on the ns-users list:
> > There were a lot of discussions on "scheduler going backwards" problem
> > in this list. I wonder what is the final solution?
>
> I think I can summarize it as follows:
>
> 1. If you see this warning, the first thing you should do is to make
> sure you're using the latest version of scheduler.cc. If necessary,
> get the latest version from
> http://www.isi.edu/cgi-bin/nsnam/cvsweb/ns-2/scheduler.cc
> Don't forget to recompile. If after that you still see this error
> message, please report this to the list.
>
> 2. If the previous didn't work for you, use Heap scheduler instead of
> default Calendar (see Simulator instproc use-scheduler command and
> nsdoc). Heap scheduler, although a little less effective than
> Calendar, doesn't have a numeric stability problem and should not
> give you this error. Again, if it does, please report this to the
> list.
- Problem: Validate does not run under Windows 95/98/NT.
Solution: See ns-build.html for instructions on how to run it. - Problem: When you run scripts it tells you something like "slot not found".
Solution:This may be due to many reasons, but if this is your first time running 2.1b6 release and you immediately see this problem, then try getting classifier-port.cc and classifier-port.h from cvs repository http://www.isi.edu/cgi-bin/nsnam/cvsweb/ns-2.
- Problem:When I use DV routing I don't get any traffic.
Solution:This is fixed in the snapshot of 14 February 2000.
You could also apply the patches in: http://www.isi.edu/nsnam/archive/ns-users/webarch/2000/msg00635.html.
- Problem:Configure on some platforms fail with this error message:
checking for tk.h... configure: error: NONE is not a directory
Solution:Apply the following patch to configure (thanks to the report and fix by Guillermo Rodriguez Garcia) :
--- configure.old Tue Feb 22 14:25:15 2000
+++ configure Mon Mar 6 12:45:35 2000
@@ -2021,7 +2021,7 @@
withval="$with_tk"
d=$withval
else
- d=$prefix
+ d=""
fi
- Problem:tcl/ex/web-traffic.tcl aborts with message:
done pages 10 != all pages 9
Solution:Apply the following patch to webcache/webtraf.cc.
- Problem: Validation fails with the on test-all-aimd with the following messages:
./test-all-aimd QUIET
Tests: tcp tcpA tcpB tcp_tahoe tcpA_tahoe tcp_reno tcpA_reno tcp_newreno tcpA_newreno
../../ns test-suite-aimd.tcl tcp QUIET
Test output agrees with reference output
../../ns test-suite-aimd.tcl tcpA QUIET
Test output agrees with reference output
../../ns test-suite-aimd.tcl tcpB QUIET
Test output agrees with reference output
../../ns test-suite-aimd.tcl tcp_tahoe QUIET
saving output for future validation
../../ns test-suite-aimd.tcl tcpA_tahoe QUIET
saving output for future validation
../../ns test-suite-aimd.tcl tcp_reno QUIET
saving output for future validation
../../ns test-suite-aimd.tcl tcpA_reno QUIET
saving output for future validation
../../ns test-suite-aimd.tcl tcp_newreno QUIET
saving output for future validation
../../ns test-suite-aimd.tcl tcpA_newreno QUIET
saving output for future validation
./test-all-template1: unknown: not found
Some test failed.
Solution: Download test-output-aimd.tar.gz and untar it at your ns-2.1b6 direcotry. - Problem: Configuration script still lists tclcl version 1.0b8 as and otcl version 1.0a5 the required versions.
Solution: Download ns-2.1b6-configure.patch and apply it to ns-2.1b6/configure.
- Problem: Some satellite examples do not exist in the release.
Solution: Download satellite-examples.tar.gz and untar it at your ns-2.1b6 directory.
- Problem: Ns doesn't generate nam traces for user-installed error modules. Reported by Sarah Liu.
Solution: Add the following patches to tcl/lib/ns-lib.tcl and tcl/lib/ns-link.tcl. Note that these patches are against the current snapshot (ns-lib version 1.139 and ns-link version 1.40). If you failed to apply them, try download the current snapshot, or use the context to apply these patches manually.
Previously, there are two major OTcl methods to install a loss module in a simple link: Simulator::lossmodel and SimpleLink::errormodule. These two methods insert an error module BEFORE the queue module in a link. Simulator::lossmodel only inserts a loss module and is not capable of producing any traces (neither ns nor nam) for packet drops. SimpleLink::errormodule is able to produce ns and nam traces, however, the nam trace can only be visualized using nam snapshots after March 3rd, 1999. After these patches, both methods have identical effects, but a new nam is still required.
In addition, two new OTcl methods are added: Simulator::link-lossmodel and SimpleLink::insert-linkloss. These two methods insert an error module AFTER the queue module. Their traces can be visualized by both the old nam and the new one.
Patch for ns-lib.tcl:
--- ns-lib.tcl 1999/02/26 23:06:34 1.139
+++ ns-lib.tcl 1999/03/04 00:12:34
@@ -1049,11 +1049,13 @@
### to insert loss module to regular links in detailed Simulator
Simulator instproc lossmodel {lossobj from to} {
set link [$self link $from $to]
- set head [$link head]
- # puts "[[$head target] info class]"
- $lossobj target [$head target]
- $head target $lossobj
- # puts "[[$head target] info class]"
+ $link errormodule $lossobj
+}
+
+# This function generates losses that can be visualized by nam.
+Simulator instproc link-lossmodel {lossobj from to} {
+ set link [$self link $from $to]
+ $link insert-linkloss $lossobj
}
Simulator instproc bw_parse { bspec } {
Patch for ns-link.tcl:--- ns-link.tcl 1998/10/28 19:26:49 1.40
+++ ns-link.tcl 1999/03/04 00:09:18
@@ -461,7 +461,7 @@
}
#
-# insert an "error module" after the queue
+# insert an "error module" BEFORE the queue
# point the em's drop-target to the drophead
#
SimpleLink instproc errormodule args {
@@ -477,3 +477,35 @@
$em drop-target $drophead_
}
+
+#
+# Insert a loss module AFTER the queue.
+#
+# Must be inserted *RIGHT AFTER* the deqT_ (if present) or queue_, because
+# nam can only visualize a packet drop if and only if it is on the link or
+# in the queue
+#
+SimpleLink instproc insert-linkloss args {
+ $self instvar link_errmodule_ queue_ drophead_ deqT_
+ if { $args == "" } {
+ return $link_errmodule_
+ }
+
+ set em [lindex $args 0]
+ if [info exists link_errmodule_] {
+ delete link_errmodule_
+ }
+ set link_errmodule_ $em
+
+ if [info exists deqT_] {
+ $em target [$deqT_ target]
+ $deqT_ target $em
+ } else {
+ $em target [$queue_ target]
+ $queue_ target $em
+ }
+
+ $em drop-target $drophead_
+}
+
+
- Problem: Static link color configuration for nam doesn't work (must use $ns at ... to change link color).
Solution: Add the following patch to tcl/lib/ns-namsupp.tcl (note this is the version in ns-2.1b4):
--- ns-namsupp.tcl~ 1998/10/06 01:26:24
+++ ns-namsupp.tcl 1999/02/16 22:48:38
@@ -143,7 +148,7 @@
set delay [$link_ set delay_]
$ns puts-nam-config \
- "l -t * -s [$fromNode_ id] -d [$toNode_ id] -S UP -r $bw -D $delay -o $attr_(ORIENTATION)"
+ "l -t * -s [$fromNode_ id] -d [$toNode_ id] -S UP -r $bw -D $delay -c $attr_(COLOR) -o $attr_(ORIENTATION)"
}
Link instproc dump-nam-queueconfig {} {
- Problem: On HP-UX 10.20 with gcc 2.7.2.2, make failed with messages like:
In file included from random.h:41,
from random.cc:40:
config.h:60: conflicting types for `typedef signed char int8_t'
/usr/include/sys/_inttypes.h:48: previous declaration as `typedef char int8_t'
In file included from random.h:41,
from random.cc:40:
config.h:92: declaration of C function `int gethostid()' conflicts with
/usr/include/sys/unistd.h:350: previous declaration `long int gethostid()' here
config.h:94: declaration of C function `void srandom(int)' conflicts with
/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.7.2.2/include/stdlib.h:265:
previous declaration `void srandom(unsigned int)' here
*** Error exit code 1
Stop.
Solution: Add the following patch into config.h:
--- config.h~ 1998/12/10 18:58:09
+++ config.h 1999/01/18 23:42:04
@@ -49,7 +49,7 @@
/* typedef signed char int8_t breaks under Solaris 2.6. Shouldn't */
/* autoconf handle stuff like this? Shouldn't autoconf generate */
/* config.h? Who knows autoconf well enough to fix this? --AMC */
-#if defined(sun)
+#if defined(sun) || defined(__hpux)
#include
typedef unsigned char u_char;
typedef unsigned short u_short;
@@ -95,8 +95,10 @@
#include
int strcasecmp(const char *, const char *);
clock_t clock(void);
+#if !defined(__hpux)
int gethostid(void);
-#if !defined(_AIX41) && !defined(sun)
+#endif
+#if !defined(_AIX41) && !defined(sun) && !defined(__hpux)
void srandom(int);
#endif
long random(void);
- Problem: On some systems ns's configure finds tclsh but compilation fails with a message like:
tclsh8.0 bin/string2c.tcl version_string < VERSION > gen/version.c
sh: tclsh8.0: not found
*** Error code 1
make: Fatal error: Command failed for target 'gen/version.c'
Reported 16 Dec 1998 by Raed Sunna.Solution: There is a bug in ns-2.1b4's configure; it only remembers that it finds tclsh8.0, not the complete path to it. This will be fixed in tonight's ns and nam snapshots; for now the work-around is to manually edit the Makefile and specify the path to tclsh on the line that begins "TCLSH =".
- Problem: On Windows 98, ns compiles fine but on trying to run ns.exe it outputs the contents of the gen/ns_tcl.cc file and exits.
Reported 27 Oct 1998 by Brett Vickers.Solution: The Makefile.vc in ns-2.1b4 release is not updated. Apply the win98.patch provided by Brett Vickers to remove the problem.
The win98.patch is as follows:
Index: makefile.vc
======================================================================
--- makefile.vc Wed Sep 2 19:15:29 1998
+++ makefile.vc Wed Oct 28 12:07:32 1998
@@ -98,7 +98,7 @@
scheduler.o object.o \
packet.o ip.o route.o connector.o ttl.o \
trace.o trace-ip.o \
- classifier.o classifier-addr.o classifier-hash.o \
+ classifier.o classifier-addr.o classifier-hash.o classifier-virtual.o \
classifier-mcast.o classifier-mpath.o replicator.o \
classifier-mac.o \
app.o telnet.o tcplib-telnet.o \
@@ -122,7 +122,7 @@
delay.o ll.o snoop.o \
channel.o mac.o mac-csma.o mac-802_11.o mac-multihop.o \
dynalink.o rtProtoDV.o net-interface.o \
- ctrMcast.o prune.o srm.o \
+ ctrMcast.o mcast_ctrl.o srm.o \
sessionhelper.o delaymodel.o srm-ssm.o \
srm-topo.o \
alloc-address.o address.o \
@@ -130,7 +130,7 @@
$(LIB_DIR)dmalloc_support.o \
webcache/http.o webcache/tcp-simple.o webcache/pagepool.o \
webcache/inval-agent.o webcache/tcpapp.o webcache/http-aux.o \
- lanRouter.o
+ lanRouter.o tfcc.o filter.o
# what was here before is now in emulate/
OBJ_C =
Index: filter.h
======================================================================
--- filter.h Tue Oct 6 14:39:34 1998
+++ filter.h Wed Oct 28 12:07:36 1998
@@ -29,11 +29,11 @@
public:
Filter();
inline NsObject* filter_target() { return filter_target_; }
+ enum filter_e { DROP, PASS, FILTER, DUPLIC };
protected:
- enum filter_e { DROP, PASS, FILTER, DUPLICATE };
virtual filter_e filter(Packet* p);
- int command(int argc, const char*const* argv);
+ int command(int argc, const char* const* argv);
void recv(Packet*, Handler* h= 0);
NsObject* filter_target_; // target for the matching packets
};
Index: filter.cc
======================================================================
--- filter.cc Wed Oct 28 13:58:50 1998
+++ filter.cc Wed Oct 28 13:58:42 1998
@@ -48,7 +48,7 @@
if (h) h->handle(p);
drop(p);
break;
- case DUPLICATE :
+ case DUPLIC :
if (filter_target_)
filter_target_->recv(p->copy(), h);
/* fallthrough */
- Problem: I can't compile embedded-tcl.cc (for example, I get the message CC:embedded-tcl.cc: line 1: compiler limit exceeded: lexical token too long. on HP-UX 10.20).
embedded-tcl.cc contains tcl code as one long string. Some compilers (like yours) can't handle strings that are so long.
Solution: (choose one or the other)
- install gcc OR
- rebuild tcl2c++ with TCL2C_INT defined, then regenerate embedded-tcl.cc with the new tcl2c++ (by deleting it and typing make after putting the new tcl2c++ in your path)
Here's the patch for HP-UX:
Index: tcl2c++.c
--- tcl2c++.c 1998/10/08 18:12:55 1.8
+++ tcl2c++.c 1998/10/12 16:40:27
@@ -30,7 +30,10 @@
#define strcasecmp _stricmp
#endif
-#if defined(WIN32) || defined(__alpha__)
+/*
+ * Define TCL2C_INT if your compiler has problems with long strings.
+ */
+#if defined(WIN32) || defined(__alpha__) || defined(__hpux)
#define TCL2C_INT
#endif
- Problem: NS breaks on trying to use single level of hierarchy for hierarchical routing.
Solution: Apply patchfile hier.patch to remove the above bug.
- Problem: mem-trace.h doesn't compile or ns fails to link because of errors about getrusage.
Solution: Ns-2.1b4 and snapshots after 15-Sep-98 should autodetect getrusage. Upgrade to those versions. Work-around: Comment out lines in mem-trace.h which reference getrusage and/or sbrk until things compile. (This will disable memory monitoring but basic ns will still work.)
- Problem: Static library of tcl-debug v1.7 on FreeBSD still contains symbols required by the dynamic libraries (crt0.o). This is caused by compiling .o files using
-fpic, and using those .o files to build static library.Solution: Apply the following patch to Makefile.in of tcl-debug v1.7:
37,38c37
< CFLAGS = @DBG_CFLAGS@
< SHCFLAGS = @DBG_CFLAGS@ @DBG_SHLIB_CFLAGS@
---
> CFLAGS = @DBG_CFLAGS@ @DBG_SHLIB_CFLAGS@
85,87d83
< SHCFLAGS_INT = $(MH_CFLAGS) $(CPPFLAGS) $(SHCFLAGS)
<
< .SUFFIXES: .so
91,92d86
< .c.so:
< $(CC) -c $(SHCFLAGS_INT) $(HDEFS) $<
96d89
< SOFILES = Dbg.so Dbg_cmd.so
114c107
< $(DBG_SHARED_LIB_FILE): $(SOFILES)
---
> $(DBG_SHARED_LIB_FILE): $(OFILES)
116c109
< @TCL_SHLIB_LD@ -o $(DBG_SHARED_LIB_FILE) $(SOFILES)
---
> @TCL_SHLIB_LD@ -o $(DBG_SHARED_LIB_FILE) $(OFILES)
Then do make distclean and re-configure and make. - Problem: Nam can not understand "V -t * -v 1.0a5". We added version infomation into nam trace file, but all nam older than version 1.0a5 can not process it. A sample error message:
nam: unknown event at offset 21 in `out.nam'
nam: `V -t * -v 1.0a5 -a 0
'
Solutions:
1. Download nam-snapshot from ns website.
or,
2. Delete the line from your nam tracefile.
(If you've done these and the problem persists, check for old versions of nam in your path.)
- Problem: namtrace-all causes segmentation fault on Linux and Solaris 2.6. It's caused by sprintf's inability to handle null pointers in those systems.
Solution: Apply the following patch to ~ns-2/trace.cc:
--- trace.cc~ 1998/07/17 22:37:25
+++ trace.cc 1998/07/20 18:07:53
@@ -185,7 +185,7 @@
hdr_rtp *rh = (hdr_rtp*)p->access(off_rtp_);
hdr_srm *sh = (hdr_srm*)p->access(off_srm_);
- const char* sname = 0;
+ const char* sname = "null";
int t = th->ptype();
const char* name = pt_names[t];
@@ -413,7 +413,7 @@
hdr_cmn *th = (hdr_cmn*)p->access(off_cmn_);
hdr_ip *iph = (hdr_ip*)p->access(off_ip_);
hdr_srm *sh = (hdr_srm*)p->access(off_srm_);
- const char* sname = 0;
+ const char* sname = "null";
int t = th->ptype();
const char* name = pt_names[t];
- Problem: When compiling ns-2.1b3 you get errors like:
object.cc: In method `void NsObject::delay_bind_init_all()':
object.cc:60: warning: implicit declaration of function `int
delay_bind_init_one(...)'
object.cc: In method `int NsObject::delay_bind_dispatch(const char *,
const char *)':
object.cc:67: warning: implicit declaration of function `int
DELAY_BIND_DISPATCH(...)'
object.cc:67: `delay_bind' undeclared (first use this function)
Solution: This error suggests you upgraded ns without upgrading tclcl. The recent ns release *requires* the current releases of otcl and tclcl.
- Problem:The script tcl/ex/test-suite-intserv.tcl fails, as does anything using the IntServ functionality.
Solution:This patch to ns-lib.tcl fixes the problem. - Problem:Multicast code breaks, because the interfaces were not installed properly, typically with an error message that goes as follows:
ns: _o3 run-mcast: invalid command name "0"
while executing
"[$link set ifacein_] set intf_label_"
(procedure "_o10" line 3)
(Node get-oif line 3)
invoked from within
"$self get-oif $link"
(procedure "_o10" line 5)
(Node init-outLink line 5)
invoked from within
"$node init-outLink"
(procedure "_o3" line 5)
(Simulator run-mcast line 5)
invoked from within
"_o3 run-mcast"
Solution: patch to ns-lib.tcl fixes the problem.
This is preferably applied after the intserv patch above.
