简介这是一套适用于网络仿真学习与科研的 NS-allinone 2.26 完整安装包包含 ns-2.26 网络模拟器及配套工具面向高校网络专业学生、研究人员和通信工程开发者可用于 MAC 层与路由层协议模拟、网络拓扑构建及流量行为分析。压缩包共 5056 个文件涵盖 tcl 仿真脚本、otcl 扩展、c/cc/h 源码、nam 动画文件、test 测试用例、文档 tex 与样例数据等整体约 50.44MB基础环境验证与二次开发均可直接使用。资源包在站内已有 108 人学习适合需要搭建离线实验环境、研读协议实现或复现经典仿真的读者使用。压缩包内部除完整源码外还包含 configure、makefile 等编译配置脚本、示例场景文件、routing/MAC 相关模块及大量验证脚本便于按需检索、对照实验记录与排错。1. NS-allinone-2.26 到底是个什么包装一次就能跑起来的 NS-2 全家桶如果你在 2024 年还要复现一篇 2008 年的论文或者课程作业里明确写着「基于 NS-2 仿真 AODV 协议」那你大概率会搜到ns-allinone-2.26.tar.gz这个包。它把 NS-2.26 主程序、Tcl/Tk 解释器、OTcl 绑定层、nam 动画工具、xgraph 绘图工具全部按固定版本打包在一起免去了手动逐个编译的版本匹配地狱。适合两类人一是被课程设计逼着跑通第一个无线仿真的本科生二是在 Linux 老环境里做协议对比实验的研究生。这个包解决的核心问题只有一个——让ns命令在十分钟内能敲出%提示符而不是把时间耗在tcl8.4.11和gcc的报错博弈里。2. 先弄懂 NS-2.26 的组成和选型逻辑allinone 包为什么比手动编译省心2.1 tar.gz 里到底裹着哪些组件ns-allinone-2.26.tar.gz不是单个程序而是一组固定版本的源码包。拆开后的目录结构是七个相互依赖的组件每个组件都有自己的configure脚本和编译入口但它们之间又有明确的调用关系。我按编译顺序把它们列在下面组件版本在系统里扮演的角色tcl8.4.11脚本解释器NS-2 的场景脚本全部由 Tcl 写成tk8.4.11Tcl 的图形库供 nam 和 xgraph 做 GUI 渲染otcl1.0.8OTcl 扩展层把 Tcl 命令映射到 C 对象ns2.26主仿真器真正的离散事件引擎和协议实现nam1.11网络动画可视化工具跑完仿真后看封包流动xgraph12.1简单的 XY 曲线绘图工具常用于吞吐量统计zlib1.2.3压缩库主要给 nam 的 trace 数据存储用这套组合是 2005 年前后 NS-2 社区非常成熟的快照。从实用角度看这个 tar.gz 的价值在于锁死了组件依赖关系otcl 1.0.8 只适配 tcl 8.4 系列ns 2.26 的tclcl通道又要求 otcl 版本不能太新。手动单独下载最新 tcl 9.0 来配 ns 2.26 是行不通的API 差异太大而这些版本匹配规则在 allinone 包里早就被写死了。我一般不去记这些版本矩阵直接把这个包当作一个整体看待。2.2 为什么是 ns-2.26而不是 NS-3 或者 2.35很多第一次接触 NS-2 的人会在这里有个疑问既然 NS-3 已经出来很多年为什么还要碰 2.26。答案得落到仿真器的架构上来看。NS-2 采用 C / OTcl 双语言分裂架构C 层负责每个协议的字节级细节、事件队列调度OTcl 层负责场景搭建、节点坐标、流量配置。这种分裂有个代价——跑一个稍大的脚本解释器会成为瓶颈仿真速度比不上 NS-3但它有一个很现实的优势修改 Agent/TCP 的窗口策略只需要在 C 里改一个成员函数不用理解 NS-3 的整个 Module 系统。至于为什么选 2.26 而不是 2.35核心原因是协议配套。无线传感器网络领域大量经典论文比如 LEACH、DSDV、AODV 的早期对比实验都是用 2.26 到 2.30 之间的版本跑出来的。2.35 虽然修了更多 bug但部分老补丁包是针对 2.26 的源码打上去的直接套到 2.35 上会有函数签名不匹配的问题。课程设计里如果老师给的参考代码写着ns-2.26的路径那用 2.26 是最稳妥的选择。这个版本还有一个隐性优势它默认的无线模型是古老的 TwoRayGround Shadowing跟经典论文里的默认参数一致跑出来的丢包曲线直接能对上文献数值。2.3 安装脚本的分工逻辑allinone 根目录下的install脚本是总入口它内部按「先依赖后主程序」的顺序逐个调用每个子目录里的configure和make。第一步编 tcl/tk第二步编 otcl第三步才编译 ns 主程序和 nam。这个顺序不能乱——ns 的configure脚本会在执行时探测 otcl 的头文件和库文件路径探测不到就直接报错退出。install脚本还有一个作用编译完成后自动生成一个ns-allinone-2.26/ns-2.26目录里的ns可执行文件软链同时把各组件编译产物按约定目录摆放好。很多人安装完只记得把ns命令加进 PATH却漏掉了LD_LIBRARY_PATH里的 otcl 和 tcl 库路径导致ns能启动但加载不了协议这个问题我后面在避坑章里展开说。理解这个分工是关键——后续所有环境变量配置都是在向系统交代「可执行文件在哪、共享库在哪、Tcl 标准库在哪」这三件事。3. 从 tar.gz 到能跑 namconfigure、make、环境变量全流程3.1 解压与 install 脚本最省心的安装入口拿到ns-allinone-2.26.tar.gz后我习惯在$HOME下建一个独立目录比如~/ns2把包解进去。这样做的原因是后续环境变量里的绝对路径最好保持稳定避免路径配到一半发现目录挪了位置导致 allinone 里的相对路径引用全部失效。解压和安装的命令如下mkdir -p ~/ns2 mv ns-allinone-2.26.tar.gz ~/ns2/ cd ~/ns2 tar zxvf ns-allinone-2.26.tar.gz cd ns-allinone-2.26 ./installtar zxvf里的z表示解压 gzip 压缩层x表示解包v是打印被解压的文件列表f指定文件名。这四个参数是归档操作的标准组合建议把v去掉也可以只是看不到进度心里没底。./install是 allinone 提供的一键脚本它会自动进入 tcl、tk、otcl、ns、nam 子目录依次执行configure make整个过程串行进行耗时取决于 CPU 性能老式双核机器上大约 15 到 20 分钟现代机器 5 分钟左右就能跑完。install 脚本跑完的最后一步会在终端打印一段提示内容大致是「请把以下路径加入环境变量」并且给出了一个source某个文件的方式。我见过不少人在这步直接关掉终端重新打开后ns: command not found慌了其实 install 只负责编译不负责改你的 shell 配置。另外需要留意一点install 脚本如果在中途报错停下来比如 otcl 编译失败那它不会继续往后编 ns。此时不要重复跑./install碰运气得先看具体报错内容典型的是编译器版本问题这个在第 4 章专门说。3.2 环境变量写到 ~/.bashrc装完才是开始编译完成只是第一步真正让ns能在任意目录下被调用靠的是四个环境变量。我一般直接在~/.bashrc末尾追加以下内容export NS_HOME$HOME/ns2/ns-allinone-2.26 export PATH$NS_HOME/bin:$NS_HOME/tcl8.4.11/unix:$NS_HOME/tk8.4.11/unix:$PATH export LD_LIBRARY_PATH$NS_HOME/tcl8.4.11/lib:$NS_HOME/tk8.4.11/lib:$NS_HOME/otcl-1.0.8:$NS_HOME/lib export TCL_LIBRARY$NS_HOME/tcl8.4.11/library第一行的NS_HOME是自定义的缩写方便后面几行引用绝对路径也方便换目录时只改一处。第二行的PATH把三个目录加进可执行文件搜索路径bin目录放着 nam 和 xgraph 的可执行文件tcl8.4.11/unix放着 tclsh 解释器tk8.4.11/unix放着 wish 图形解释器。第三行是动态库搜索路径这是最容易漏的。ns 启动时要加载libotcl.so和libtclcl.so如果你不加 otcl 的目录到LD_LIBRARY_PATHns 能启动但一加载协议扩展就报symbol lookup error非常难排查。第四行的TCL_LIBRARY指向 Tcl 标准库源码目录ns 的仿真脚本里用到package require时会从这里找包定义。配置完成后一定要source ~/.bashrc让变量在当前 shell 生效然后重新打开一个终端测试。如果用户在 Ubuntu 或 CentOS 上用的是 zsh那就得改~/.zshrc而不是~/.bashrc这个细节很多人栽过。3.3 验证安装ns 能进 % 提示符才算过环境变量配好后需要做三层验证第一层验证ns命令能被找到第二层验证 Tcl 解释器能执行基础命令第三层验证 nam 可视化工具能起来。我习惯按下面的顺序来which ns ns % puts hello ns, allinone 2.26 ok hello ns, allinone 2.26 ok % exit如果which ns返回了路径说明 PATH 配对了进入%提示符说明 ns 主程序能启动能正确执行puts说明 Tcl 解释器正常工作。这一步卡住的人八成是第二层环境变量没配全。注意ns和tclsh不是一回事ns是带 ns-2 扩展的 Tcl 解释器在 ns 里能用的new Simulator命令在tclsh里是不存在的。所以验证 NS-2 安装必须用ns不要用系统自带的 tclsh 做替代测试。验证 nam 和环境变量是否完整可以跑一个小脚本测试运行cd ~/ns2/ns-allinone-2.26/ns-2.26/tcl/ex ns simple.tclsimple.tcl是 NS-2 自带的最小拓扑脚本一个 TCP 连接两个节点跑完会自动生成out.tr和out.nam两个文件。正常执行完后用ns路径/bin/nam out.nam能看到网络动画。如果 nam 窗口一闪而过或者直接报nam: error while loading shared libraries说明 LD_LIBRARY_PATH 里 nam 依赖的 Tk 库路径不对检查$NS_HOME/tk8.4.11/lib是否存在以及libtk8.4.so是否在这个目录下。3.4 编译遇到 configure 报错时的处理套路./install过程中最常见的非环境变量问题是某个子组件的 configure 脚本检测不到前置依赖。比如 otcl 的 configure 会检查 tcl 安装路径ns 的 configure 会检查 otcl 的头文件。这类报错有几类特征模板第一类是无法指定 libtcl 的位置信息是checking for Tcl library... not found遇到这个可以把 tcl 的路径显式传给 configure 脚本但我更推荐先确认 tcl 是否真的编译成功。另一类是 C 编译器版本不兼容导致的模板实例化报错比如error: static specified invalid for parameter。这类报错在 Ubuntu 22.04 上非常密集原因是 ns-2.26 的底层代码写于 2005 年前后用的 C 标准还是 C98 的早期风格新编译器的检查更严格。处理这个问题的正统方案在第 4 章避坑章节会给简单说就是不要跟新 gcc 硬刚要么装老版本 gcc要么用 Docker 跑一个老系统镜像。相较于反复折腾编译器版本我强烈推荐后一种方案一条命令进容器隔离干净换机器可重复。4. 常见问题与避坑NS-2.26 安装与运行的典型翻车点4.1 gcc 版本太高导致编译报错最常见的第一道坎现象./install跑到 otcl 或 ns 子目录时编译输出大量error: invalid conversion from int to ...或者直接提示template with C linkage之类完全看不懂的底层报错。最典型的是在同一台 Ubuntu 22.04 上tcl 和 tk 编得顺顺利利到了 otcl 突然崩掉。原因ns-2.26 的源码写的年代比较早默认假设编译器允许隐式类型转换和宽松的函数指针检查。GCC 从 4.6 开始收紧了部分规则到 GCC 8 之后默认启用的-fno-common和更严格的模板检查让老代码大规模翻车。这不是环境变量的问题也不是包损坏的问题是代码与编译器标准之间的代沟。解决最省事的方案是装一个 GCC 4.4 或 4.6 版本然后修改ins-allinone-2.26/install脚本里的编译器变量或者手动进各子目录执行configure CCgcc-4.4 CXXg-4.4。但 Ubuntu 20.04 以上的官方仓库里已经移除了 gcc-4.4装不上。我个人现在统一走 Docker 方案直接拉一个 Ubuntu 16.04 镜像在里面apt-get install gcc-4.4 g-4.4然后把 ns-allinone-2.26 挂载进去编译。16.04 自带 gcc 5.4 也能编过大部分子组件装 gcc-4.4 更保险。注意这一步拉的是公开的标准镜像和编译器跟网络加速没有任何关系别被老教程里那些模糊的词带偏。4.2 nam 起不来或者闪退动态库路径残缺现象ns命令正常simple.tcl也能跑出 trace 文件但执行nam out.nam时报错nam: error while loading shared libraries: libtk8.4.so: cannot open shared object file: No such file or directory或者 nam 窗口显示两秒就自动退出。原因nam 是 Tk 的客户程序它启动时要找libtk8.4.so和libtcl8.4.so。如果你的LD_LIBRARY_PATH里漏掉了tk8.4.11/lib或者路径写错了动态链接器就找不到这个库。另一个常见原因是 nam 和 tk 编译时的安装路径不一致比如你移动过 allinone 的目录configure 时记录的prefix路径就失效了。解决先确认库文件实际位置执行find $NS_HOME -name libtk8.4.so然后用ldd $(which nam)查看 nam 实际依赖了哪些库以及哪些显示 not found。定位到缺失库之后把它的绝对路径补到LD_LIBRARY_PATH的最前面再执行ldconfig刷新。如果 nam 是闪退而不是报缺库多半是 OpenGL 渲染的问题把虚拟机的 3D 加速打开即可跟软件本身无关。4.3 运行 Tcl 脚本报couldnt read file lib/ns-2.26/tcl现象写好的仿真脚本执行ns wireless.tclns 启动后立刻输出couldnt read file lib/ns-2.26/tcl: no such file or directory然后退出。新建的脚本里明明引用了正确的路径为什么 ns 找不到自己的标准库。原因ns 可执行文件在启动时默认去相对路径lib/ns-2.26/tcl加载 Tcl 命令集的补充文件。这个相对路径是相对于当前工作目录计算出来的。你从~/ns2/ns-allinone-2.26/ns-2.26目录下启动 ns 时它能找到但如果你在根目录或别的路径执行ns /path/to/wireless.tcl那这个默认相对路径就失效了。解决这套老版本 NS-2 的最佳实践是永远把仿真脚本放在~/ns2/ns-allinone-2.26/ns-2.26目录或其子目录下运行。如果要在别的目录用可以在脚本开头加上一行$env(NS_HOME)拼出绝对路径或者写一个ns的软链包装脚本启动时先cd到 ns 的安装目录再执行。我一般最省心的做法是直接在tcl/ex目录下建自己的实验子目录所有脚本从那里跑从根源上避开相对路径问题。4.4 xgraph 无法启动或者画出的曲线是空的现象在tcl/ex里跑完带xgraph调用的脚本后终端显示xgraph: Command not found或者 xgraph 能弹窗但窗口里没有任何曲线数据显示graf 文件生成了但内容不对。原因xgraph 是独立可执行文件它在$NS_HOME/bin下。如果 PATH 没配好命令找不到是第一个问题。而第二个问题更隐蔽——xgraph 读的是特定字段格式的数据文件通常由 gawk 脚本从 trace 文件里提取生成。如果你在脚本里调用 exec xgraph 时传的文件路径写错了或者 trace 里本来就是零数据xgraph 就会显示空白。这类空数据问题往往不是 xgraph 坏了而是上游的 awk 提取脚本统计条件写错。解决先单独在终端执行xgraph -version验证工具本身能启动然后检查确认 graf 文件里有非空内容比如用cat out.graf | head -20。如果 graf 文件为空或者只有一行回过去检查 awk 脚本的统计逻辑。我习惯的做法是把 awk 统计结果先存成delay.graf文件人工打开看一遍数值合理后再调用 xgraph 绘图而不是让 NS 脚本直接 exec xgraph 绕过了中间检查环节。4.5 修改协议源码后重编不生效make 缓存坑现象改了~/ns-2.26/tcp/tcp-sink.cc里的某个函数重新执行 make编译显示完成但没有报错可运行脚本时结果跟改前一模一样仿佛代码白改。原因ns-2.26 的 make 系统是老的递归 make 架构当你在ns-2.26根目录下修改了一个子目录里的.cc文件后再执行 make很多版本的 makefile 依赖关系没有正确追踪头文件的变化导致它认为不需要重新编译你修改的那个目标文件直接跳过。解决在修改任何 C 文件后光 make 不保险。我每次改完协议源码都执行一次make clean make虽然多花几分钟但能保证全量重编。另外ns-2.26 的 makefile 里经常透传CFLAGS你如果为了调试加了-g选项记得确认它加到了正确的位置否则编译出来的目标文件可能没有生效。这个翻车点属于「玄学」最多的区域建议养成修改一个源文件就记录时间点的习惯用ls -l查看改名文件是否真正被重编译过。5. 从零写一个丢包率验证脚本把 NS-2.26 装到能用再装到能用透安装不是终点能写出自己的仿真脚本才算彻底掌握 NS-2.26。这里给你一个最小但完整的随机丢包验证脚本核心是用一个 UDP 流和 Droptail 队列观察丢包数set ns [new Simulator] set f [open drop.tr w] $ns trace-all $f set n0 [$ns node] set n1 [$ns node] $ns duplex-link $n0 $n1 1Mb 5ms DropTail set udp [new Agent/UDP] $ns attach-agent $n0 $udp set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp $cbr set packetSize_ 500 $cbr set rate_ 1.5Mb set null [new Agent/Null] $ns attach-agent $n1 $null $ns connect $udp $null $ns run这个脚本故意把 CBR 速率设为 1.5Mb而上行链路带宽只有 1Mb这样路由器一侧必然出现队列溢出。DropTail队列的默认长度是 10 个包当 CBR 每 0.005 秒发一个 500 字节的包时队列会被打满多余包被丢弃。执行ns cbr-test.tcl生成drop.tr然后看 trace 文件确认丢包行为。trace 文件里四个事件的标记含义是入队、-出队、r接收、d丢弃。用grep ^d drop.tr | wc -l统计丢弃行数如果数字大于零说明队列极限和丢包逻辑工作正常——这是你验证 NS-2.26 协议栈没有安装损坏的最有力证据。如果丢包数为零多半是队列长度设得太大或者仿真时间太短可以把链路带宽从 1Mb 降到 500Kb并加长运行时间例如在$ns run前加$ns at 5.0 $ns halt这种控制语句。参数怎么调平台已经向你展示清楚了修改rate_和packetSize_可以控制流量压力修改DropTail的limit_可以控制队列缓冲。从那以后我每次装完 NS-2.26 都会强制跑一遍上面这个小脚本确认d事件真的能被 trace 出来才去动协议源码——这一步能省下后面排查环境问题的大量时间希望帮到你。本文还有配套的精品资源点击获取 NS-allinone-2.26安装全攻略：从零跑通NS-2网络仿真环境
简介这是一套适用于网络仿真学习与科研的 NS-allinone 2.26 完整安装包包含 ns-2.26 网络模拟器及配套工具面向高校网络专业学生、研究人员和通信工程开发者可用于 MAC 层与路由层协议模拟、网络拓扑构建及流量行为分析。压缩包共 5056 个文件涵盖 tcl 仿真脚本、otcl 扩展、c/cc/h 源码、nam 动画文件、test 测试用例、文档 tex 与样例数据等整体约 50.44MB基础环境验证与二次开发均可直接使用。资源包在站内已有 108 人学习适合需要搭建离线实验环境、研读协议实现或复现经典仿真的读者使用。压缩包内部除完整源码外还包含 configure、makefile 等编译配置脚本、示例场景文件、routing/MAC 相关模块及大量验证脚本便于按需检索、对照实验记录与排错。1. NS-allinone-2.26 到底是个什么包装一次就能跑起来的 NS-2 全家桶如果你在 2024 年还要复现一篇 2008 年的论文或者课程作业里明确写着「基于 NS-2 仿真 AODV 协议」那你大概率会搜到ns-allinone-2.26.tar.gz这个包。它把 NS-2.26 主程序、Tcl/Tk 解释器、OTcl 绑定层、nam 动画工具、xgraph 绘图工具全部按固定版本打包在一起免去了手动逐个编译的版本匹配地狱。适合两类人一是被课程设计逼着跑通第一个无线仿真的本科生二是在 Linux 老环境里做协议对比实验的研究生。这个包解决的核心问题只有一个——让ns命令在十分钟内能敲出%提示符而不是把时间耗在tcl8.4.11和gcc的报错博弈里。2. 先弄懂 NS-2.26 的组成和选型逻辑allinone 包为什么比手动编译省心2.1 tar.gz 里到底裹着哪些组件ns-allinone-2.26.tar.gz不是单个程序而是一组固定版本的源码包。拆开后的目录结构是七个相互依赖的组件每个组件都有自己的configure脚本和编译入口但它们之间又有明确的调用关系。我按编译顺序把它们列在下面组件版本在系统里扮演的角色tcl8.4.11脚本解释器NS-2 的场景脚本全部由 Tcl 写成tk8.4.11Tcl 的图形库供 nam 和 xgraph 做 GUI 渲染otcl1.0.8OTcl 扩展层把 Tcl 命令映射到 C 对象ns2.26主仿真器真正的离散事件引擎和协议实现nam1.11网络动画可视化工具跑完仿真后看封包流动xgraph12.1简单的 XY 曲线绘图工具常用于吞吐量统计zlib1.2.3压缩库主要给 nam 的 trace 数据存储用这套组合是 2005 年前后 NS-2 社区非常成熟的快照。从实用角度看这个 tar.gz 的价值在于锁死了组件依赖关系otcl 1.0.8 只适配 tcl 8.4 系列ns 2.26 的tclcl通道又要求 otcl 版本不能太新。手动单独下载最新 tcl 9.0 来配 ns 2.26 是行不通的API 差异太大而这些版本匹配规则在 allinone 包里早就被写死了。我一般不去记这些版本矩阵直接把这个包当作一个整体看待。2.2 为什么是 ns-2.26而不是 NS-3 或者 2.35很多第一次接触 NS-2 的人会在这里有个疑问既然 NS-3 已经出来很多年为什么还要碰 2.26。答案得落到仿真器的架构上来看。NS-2 采用 C / OTcl 双语言分裂架构C 层负责每个协议的字节级细节、事件队列调度OTcl 层负责场景搭建、节点坐标、流量配置。这种分裂有个代价——跑一个稍大的脚本解释器会成为瓶颈仿真速度比不上 NS-3但它有一个很现实的优势修改 Agent/TCP 的窗口策略只需要在 C 里改一个成员函数不用理解 NS-3 的整个 Module 系统。至于为什么选 2.26 而不是 2.35核心原因是协议配套。无线传感器网络领域大量经典论文比如 LEACH、DSDV、AODV 的早期对比实验都是用 2.26 到 2.30 之间的版本跑出来的。2.35 虽然修了更多 bug但部分老补丁包是针对 2.26 的源码打上去的直接套到 2.35 上会有函数签名不匹配的问题。课程设计里如果老师给的参考代码写着ns-2.26的路径那用 2.26 是最稳妥的选择。这个版本还有一个隐性优势它默认的无线模型是古老的 TwoRayGround Shadowing跟经典论文里的默认参数一致跑出来的丢包曲线直接能对上文献数值。2.3 安装脚本的分工逻辑allinone 根目录下的install脚本是总入口它内部按「先依赖后主程序」的顺序逐个调用每个子目录里的configure和make。第一步编 tcl/tk第二步编 otcl第三步才编译 ns 主程序和 nam。这个顺序不能乱——ns 的configure脚本会在执行时探测 otcl 的头文件和库文件路径探测不到就直接报错退出。install脚本还有一个作用编译完成后自动生成一个ns-allinone-2.26/ns-2.26目录里的ns可执行文件软链同时把各组件编译产物按约定目录摆放好。很多人安装完只记得把ns命令加进 PATH却漏掉了LD_LIBRARY_PATH里的 otcl 和 tcl 库路径导致ns能启动但加载不了协议这个问题我后面在避坑章里展开说。理解这个分工是关键——后续所有环境变量配置都是在向系统交代「可执行文件在哪、共享库在哪、Tcl 标准库在哪」这三件事。3. 从 tar.gz 到能跑 namconfigure、make、环境变量全流程3.1 解压与 install 脚本最省心的安装入口拿到ns-allinone-2.26.tar.gz后我习惯在$HOME下建一个独立目录比如~/ns2把包解进去。这样做的原因是后续环境变量里的绝对路径最好保持稳定避免路径配到一半发现目录挪了位置导致 allinone 里的相对路径引用全部失效。解压和安装的命令如下mkdir -p ~/ns2 mv ns-allinone-2.26.tar.gz ~/ns2/ cd ~/ns2 tar zxvf ns-allinone-2.26.tar.gz cd ns-allinone-2.26 ./installtar zxvf里的z表示解压 gzip 压缩层x表示解包v是打印被解压的文件列表f指定文件名。这四个参数是归档操作的标准组合建议把v去掉也可以只是看不到进度心里没底。./install是 allinone 提供的一键脚本它会自动进入 tcl、tk、otcl、ns、nam 子目录依次执行configure make整个过程串行进行耗时取决于 CPU 性能老式双核机器上大约 15 到 20 分钟现代机器 5 分钟左右就能跑完。install 脚本跑完的最后一步会在终端打印一段提示内容大致是「请把以下路径加入环境变量」并且给出了一个source某个文件的方式。我见过不少人在这步直接关掉终端重新打开后ns: command not found慌了其实 install 只负责编译不负责改你的 shell 配置。另外需要留意一点install 脚本如果在中途报错停下来比如 otcl 编译失败那它不会继续往后编 ns。此时不要重复跑./install碰运气得先看具体报错内容典型的是编译器版本问题这个在第 4 章专门说。3.2 环境变量写到 ~/.bashrc装完才是开始编译完成只是第一步真正让ns能在任意目录下被调用靠的是四个环境变量。我一般直接在~/.bashrc末尾追加以下内容export NS_HOME$HOME/ns2/ns-allinone-2.26 export PATH$NS_HOME/bin:$NS_HOME/tcl8.4.11/unix:$NS_HOME/tk8.4.11/unix:$PATH export LD_LIBRARY_PATH$NS_HOME/tcl8.4.11/lib:$NS_HOME/tk8.4.11/lib:$NS_HOME/otcl-1.0.8:$NS_HOME/lib export TCL_LIBRARY$NS_HOME/tcl8.4.11/library第一行的NS_HOME是自定义的缩写方便后面几行引用绝对路径也方便换目录时只改一处。第二行的PATH把三个目录加进可执行文件搜索路径bin目录放着 nam 和 xgraph 的可执行文件tcl8.4.11/unix放着 tclsh 解释器tk8.4.11/unix放着 wish 图形解释器。第三行是动态库搜索路径这是最容易漏的。ns 启动时要加载libotcl.so和libtclcl.so如果你不加 otcl 的目录到LD_LIBRARY_PATHns 能启动但一加载协议扩展就报symbol lookup error非常难排查。第四行的TCL_LIBRARY指向 Tcl 标准库源码目录ns 的仿真脚本里用到package require时会从这里找包定义。配置完成后一定要source ~/.bashrc让变量在当前 shell 生效然后重新打开一个终端测试。如果用户在 Ubuntu 或 CentOS 上用的是 zsh那就得改~/.zshrc而不是~/.bashrc这个细节很多人栽过。3.3 验证安装ns 能进 % 提示符才算过环境变量配好后需要做三层验证第一层验证ns命令能被找到第二层验证 Tcl 解释器能执行基础命令第三层验证 nam 可视化工具能起来。我习惯按下面的顺序来which ns ns % puts hello ns, allinone 2.26 ok hello ns, allinone 2.26 ok % exit如果which ns返回了路径说明 PATH 配对了进入%提示符说明 ns 主程序能启动能正确执行puts说明 Tcl 解释器正常工作。这一步卡住的人八成是第二层环境变量没配全。注意ns和tclsh不是一回事ns是带 ns-2 扩展的 Tcl 解释器在 ns 里能用的new Simulator命令在tclsh里是不存在的。所以验证 NS-2 安装必须用ns不要用系统自带的 tclsh 做替代测试。验证 nam 和环境变量是否完整可以跑一个小脚本测试运行cd ~/ns2/ns-allinone-2.26/ns-2.26/tcl/ex ns simple.tclsimple.tcl是 NS-2 自带的最小拓扑脚本一个 TCP 连接两个节点跑完会自动生成out.tr和out.nam两个文件。正常执行完后用ns路径/bin/nam out.nam能看到网络动画。如果 nam 窗口一闪而过或者直接报nam: error while loading shared libraries说明 LD_LIBRARY_PATH 里 nam 依赖的 Tk 库路径不对检查$NS_HOME/tk8.4.11/lib是否存在以及libtk8.4.so是否在这个目录下。3.4 编译遇到 configure 报错时的处理套路./install过程中最常见的非环境变量问题是某个子组件的 configure 脚本检测不到前置依赖。比如 otcl 的 configure 会检查 tcl 安装路径ns 的 configure 会检查 otcl 的头文件。这类报错有几类特征模板第一类是无法指定 libtcl 的位置信息是checking for Tcl library... not found遇到这个可以把 tcl 的路径显式传给 configure 脚本但我更推荐先确认 tcl 是否真的编译成功。另一类是 C 编译器版本不兼容导致的模板实例化报错比如error: static specified invalid for parameter。这类报错在 Ubuntu 22.04 上非常密集原因是 ns-2.26 的底层代码写于 2005 年前后用的 C 标准还是 C98 的早期风格新编译器的检查更严格。处理这个问题的正统方案在第 4 章避坑章节会给简单说就是不要跟新 gcc 硬刚要么装老版本 gcc要么用 Docker 跑一个老系统镜像。相较于反复折腾编译器版本我强烈推荐后一种方案一条命令进容器隔离干净换机器可重复。4. 常见问题与避坑NS-2.26 安装与运行的典型翻车点4.1 gcc 版本太高导致编译报错最常见的第一道坎现象./install跑到 otcl 或 ns 子目录时编译输出大量error: invalid conversion from int to ...或者直接提示template with C linkage之类完全看不懂的底层报错。最典型的是在同一台 Ubuntu 22.04 上tcl 和 tk 编得顺顺利利到了 otcl 突然崩掉。原因ns-2.26 的源码写的年代比较早默认假设编译器允许隐式类型转换和宽松的函数指针检查。GCC 从 4.6 开始收紧了部分规则到 GCC 8 之后默认启用的-fno-common和更严格的模板检查让老代码大规模翻车。这不是环境变量的问题也不是包损坏的问题是代码与编译器标准之间的代沟。解决最省事的方案是装一个 GCC 4.4 或 4.6 版本然后修改ins-allinone-2.26/install脚本里的编译器变量或者手动进各子目录执行configure CCgcc-4.4 CXXg-4.4。但 Ubuntu 20.04 以上的官方仓库里已经移除了 gcc-4.4装不上。我个人现在统一走 Docker 方案直接拉一个 Ubuntu 16.04 镜像在里面apt-get install gcc-4.4 g-4.4然后把 ns-allinone-2.26 挂载进去编译。16.04 自带 gcc 5.4 也能编过大部分子组件装 gcc-4.4 更保险。注意这一步拉的是公开的标准镜像和编译器跟网络加速没有任何关系别被老教程里那些模糊的词带偏。4.2 nam 起不来或者闪退动态库路径残缺现象ns命令正常simple.tcl也能跑出 trace 文件但执行nam out.nam时报错nam: error while loading shared libraries: libtk8.4.so: cannot open shared object file: No such file or directory或者 nam 窗口显示两秒就自动退出。原因nam 是 Tk 的客户程序它启动时要找libtk8.4.so和libtcl8.4.so。如果你的LD_LIBRARY_PATH里漏掉了tk8.4.11/lib或者路径写错了动态链接器就找不到这个库。另一个常见原因是 nam 和 tk 编译时的安装路径不一致比如你移动过 allinone 的目录configure 时记录的prefix路径就失效了。解决先确认库文件实际位置执行find $NS_HOME -name libtk8.4.so然后用ldd $(which nam)查看 nam 实际依赖了哪些库以及哪些显示 not found。定位到缺失库之后把它的绝对路径补到LD_LIBRARY_PATH的最前面再执行ldconfig刷新。如果 nam 是闪退而不是报缺库多半是 OpenGL 渲染的问题把虚拟机的 3D 加速打开即可跟软件本身无关。4.3 运行 Tcl 脚本报couldnt read file lib/ns-2.26/tcl现象写好的仿真脚本执行ns wireless.tclns 启动后立刻输出couldnt read file lib/ns-2.26/tcl: no such file or directory然后退出。新建的脚本里明明引用了正确的路径为什么 ns 找不到自己的标准库。原因ns 可执行文件在启动时默认去相对路径lib/ns-2.26/tcl加载 Tcl 命令集的补充文件。这个相对路径是相对于当前工作目录计算出来的。你从~/ns2/ns-allinone-2.26/ns-2.26目录下启动 ns 时它能找到但如果你在根目录或别的路径执行ns /path/to/wireless.tcl那这个默认相对路径就失效了。解决这套老版本 NS-2 的最佳实践是永远把仿真脚本放在~/ns2/ns-allinone-2.26/ns-2.26目录或其子目录下运行。如果要在别的目录用可以在脚本开头加上一行$env(NS_HOME)拼出绝对路径或者写一个ns的软链包装脚本启动时先cd到 ns 的安装目录再执行。我一般最省心的做法是直接在tcl/ex目录下建自己的实验子目录所有脚本从那里跑从根源上避开相对路径问题。4.4 xgraph 无法启动或者画出的曲线是空的现象在tcl/ex里跑完带xgraph调用的脚本后终端显示xgraph: Command not found或者 xgraph 能弹窗但窗口里没有任何曲线数据显示graf 文件生成了但内容不对。原因xgraph 是独立可执行文件它在$NS_HOME/bin下。如果 PATH 没配好命令找不到是第一个问题。而第二个问题更隐蔽——xgraph 读的是特定字段格式的数据文件通常由 gawk 脚本从 trace 文件里提取生成。如果你在脚本里调用 exec xgraph 时传的文件路径写错了或者 trace 里本来就是零数据xgraph 就会显示空白。这类空数据问题往往不是 xgraph 坏了而是上游的 awk 提取脚本统计条件写错。解决先单独在终端执行xgraph -version验证工具本身能启动然后检查确认 graf 文件里有非空内容比如用cat out.graf | head -20。如果 graf 文件为空或者只有一行回过去检查 awk 脚本的统计逻辑。我习惯的做法是把 awk 统计结果先存成delay.graf文件人工打开看一遍数值合理后再调用 xgraph 绘图而不是让 NS 脚本直接 exec xgraph 绕过了中间检查环节。4.5 修改协议源码后重编不生效make 缓存坑现象改了~/ns-2.26/tcp/tcp-sink.cc里的某个函数重新执行 make编译显示完成但没有报错可运行脚本时结果跟改前一模一样仿佛代码白改。原因ns-2.26 的 make 系统是老的递归 make 架构当你在ns-2.26根目录下修改了一个子目录里的.cc文件后再执行 make很多版本的 makefile 依赖关系没有正确追踪头文件的变化导致它认为不需要重新编译你修改的那个目标文件直接跳过。解决在修改任何 C 文件后光 make 不保险。我每次改完协议源码都执行一次make clean make虽然多花几分钟但能保证全量重编。另外ns-2.26 的 makefile 里经常透传CFLAGS你如果为了调试加了-g选项记得确认它加到了正确的位置否则编译出来的目标文件可能没有生效。这个翻车点属于「玄学」最多的区域建议养成修改一个源文件就记录时间点的习惯用ls -l查看改名文件是否真正被重编译过。5. 从零写一个丢包率验证脚本把 NS-2.26 装到能用再装到能用透安装不是终点能写出自己的仿真脚本才算彻底掌握 NS-2.26。这里给你一个最小但完整的随机丢包验证脚本核心是用一个 UDP 流和 Droptail 队列观察丢包数set ns [new Simulator] set f [open drop.tr w] $ns trace-all $f set n0 [$ns node] set n1 [$ns node] $ns duplex-link $n0 $n1 1Mb 5ms DropTail set udp [new Agent/UDP] $ns attach-agent $n0 $udp set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp $cbr set packetSize_ 500 $cbr set rate_ 1.5Mb set null [new Agent/Null] $ns attach-agent $n1 $null $ns connect $udp $null $ns run这个脚本故意把 CBR 速率设为 1.5Mb而上行链路带宽只有 1Mb这样路由器一侧必然出现队列溢出。DropTail队列的默认长度是 10 个包当 CBR 每 0.005 秒发一个 500 字节的包时队列会被打满多余包被丢弃。执行ns cbr-test.tcl生成drop.tr然后看 trace 文件确认丢包行为。trace 文件里四个事件的标记含义是入队、-出队、r接收、d丢弃。用grep ^d drop.tr | wc -l统计丢弃行数如果数字大于零说明队列极限和丢包逻辑工作正常——这是你验证 NS-2.26 协议栈没有安装损坏的最有力证据。如果丢包数为零多半是队列长度设得太大或者仿真时间太短可以把链路带宽从 1Mb 降到 500Kb并加长运行时间例如在$ns run前加$ns at 5.0 $ns halt这种控制语句。参数怎么调平台已经向你展示清楚了修改rate_和packetSize_可以控制流量压力修改DropTail的limit_可以控制队列缓冲。从那以后我每次装完 NS-2.26 都会强制跑一遍上面这个小脚本确认d事件真的能被 trace 出来才去动协议源码——这一步能省下后面排查环境问题的大量时间希望帮到你。本文还有配套的精品资源点击获取