企业官网建设流程全解析

简介：无线网络技术（无线网络应用）课程的完整实验报告合集，涵盖必做与选作实验，面向高校网络工程、通信工程等专业学生，也适合实验课复习和无线网络入门者参考。报告围绕典型无线网络实验场景展开，包括虚拟服务器与防火墙安全配置、WEP/WPA-PSK加密方式对比、DHCP服务器动态地址分配、无线AP的Bridge与Client组网等，内容具体到TP-LINK无线路由器、TL-WA801N等设备的操作步骤。每份实验报告均按实验目的、原理、主要仪器设备、操作步骤、结果分析与讨论心得的结构整理，并包含具体的配置界面与验证细节，便于读者对照环境复现。资源为单个PDF文件，共1个文件，大小6.11MB，排版清晰，下载后可通读全部实验要点或按需打印。目前已有139人浏览学习，说明这份报告对同类课程学习者有一定参考价值。

1. 这份 PDF 里真正值得抄的不是命令，是报告的分析视角

无线网络技术这门课，很多人的实验报告都是「开头抄原理、中间贴抓包截图、结尾写‘通过本实验我掌握了……’」的流水账。如果你也在赶这门课的实验报告，或者在准备补交一份能拿得出手的版本，这份《无线网络技术全部实验报告(含选作实验)要点》PDF 的价值，不在于它替你把命令都列全了——命令网上到处都是——而在于它把每个实验拆成了「要抓什么帧、看哪些字段、参数怎么改、结果说明什么」四步。下面按做实验的先后顺序展开讲：环境怎么搭、必做实验怎么做、坑在哪、选作怎么加分。

2. 先搭好能出结果的环境：监控模式、Wireshark 过滤器与三个必用字段

抓包实验有个很反直觉的起点：不是先开 Wireshark，而是先确认网卡能不能让你看到别人的帧。这一章把环境讲透，后面所有实验才有意义。

2.1 网卡能不能进监控模式，决定哪些帧会出现在抓包里

默认手机和笔记本里的无线网卡工作在 STA 模式，硬件只会把发给自己的数据帧交给驱动；周围其他终端发的管理帧、控制帧一概不理会。所以在普通模式下打开 Wireshark，看到的内容少得可怜。做无线网络技术实验，第一步是把网卡切到 monitor（监控）模式。监控模式下网卡不关联任何 AP，把空气里能解调出来的 802.11 帧全部带一个 radiotap 头交给抓包工具，Beacon、Probe、RTS/CTS 这些帧才可能出现在 pcap 文件里。

先确认手里的网卡支持 monitor。Linux 下用一条命令就能看：iw list输出里的 Supported interface modes 是否包含 monitor。多数笔记本内置网卡的驱动（尤其较新的内核）没有开放 monitor 接口，这也是很多同学在一台笔记本上怎么抓都抓不到周围 Beacon 的根本原因。解决方式是准备一块 USB 无线网卡，芯片选常见的 Atheros、Realtek、Ralink 系列，驱动兼容性好，实验报告里网卡型号、芯片、驱动版本三行信息也建议写清楚，这个细节在评审时很加分。

# 查看网卡支持哪些 interface mode iw list | grep -A 8 "Supported interface modes" # 用 airmon-ng 把 wlan0 切到监控模式，成功后会出现 wlan0mon sudo airmon-ng start wlan0 # 确认新接口存在、类型是 monitor iw dev wlan0mon info

如果airmon-ng start在新内核上报 unknown command 或接口没起来，就手动切：先sudo ip link set wlan0 down，再sudo iw dev wlan0 set type monitor，最后sudo ip link set wlan0 up。两种方式选一种即可，不用两个都执行。注意iw手动切换前必须先把网卡 down 掉，否则会报 device or resource busy；airmon-ng的好处是它会自己处理 netif 状态，坏处是它依赖驱动对 rfkill 的处理，某些网卡切完会掉线，需要重新插拔一次。

在虚拟机里跑这套，USB 网卡要先从宿主机解绑再直通给虚拟机，否则 Wireshark 看到的还是空接口；更省心的做法是直接在物理机上跑抓包终端。接下来固定信道：2.4G 里选 1、6、11 中的一个，比如sudo airodump-ng wlan0mon --channel 6，固定在同一个信道里抓，报告的时序才不乱。如果不固定信道，网卡在 1~13 信道间跳频，Beacon 时有时无，很多时间间隔的分析就没法做了。

提示：开启了监控模式的网卡会断开当前 WiFi 连接，实验前先保存好需要联网的材料。

2.2 管理帧、控制帧、数据帧怎么分：一张表和一个过滤器习惯

802.11 帧的 Frame Control 字段里有 2 bit Type 和 4 bit Subtype，Wireshark 把它们合并成一个字段wlan.fc.type_subtype。抓到的任何帧，第一步先看这个字段，判断自己面对的是哪类帧。管理帧负责连接生命周期（Beacon、Probe、Auth、Assoc），控制帧负责信道访问协调（RTS、CTS、ACK），数据帧才承载真正的业务流量。实验报告里写「本帧是管理帧中的 Beacon 帧」，依据就是wlan.fc.type_subtype的取值，这个字段是报告的三个必用字段之一。

只看 Type 不够，还要知道这帧是谁发给谁的。wlan.sa是源地址，wlan.da是目的地址，wlan.bssid是所在 BSS 的标识。AP 发出的 Beacon 里 sa 和 bssid 是同一个 MAC；终端发给 AP 的数据帧里 bssid 是 AP 的 MAC。判断业务方向时用另外两个位：wlan.fc.tods=1表示发往 AP 的帧，wlan.fc.frmods=1表示来自 AP 的帧。所以报告里写「检测到终端到 AP 的上行数据帧」，光看 IP 层不严谨，要把这两个标志位一起写上。

在 Wireshark 里设好显示过滤器，GUI 里看树形解码；批量整理数据时我用 tshark 直接抽字段，输出成 tab 分隔文本，粘到表格软件里就是一张干净的分析底稿：

# 从 pcap 里抽出所有管理帧的四个关键字段 tshark -r lab.pcapng \ -Y "wlan.fc.type == 0" \ -T fields \ -e frame.number -e frame.time \ -e wlan.sa -e wlan.da -e wlan.fc.type_subtype

说明：-Y是显示过滤器，只留满足条件的帧；-T fields关闭普通输出，改成按-e指定的字段逐行打印；frame.number是帧序号，报告附录里引用原始帧时写这个号就行。这个命令不会改原 pcap 文件，输出重定向到 txt 后可以反复重跑，适合在不同过滤器条件下对比同一组抓包数据。

再强调一个我建议的报告习惯：每张关键抓包截图下面放一行表格，列名是「帧号、相对时间、源地址、目的地址、type_subtype、字段说明」，这样分析者和评分人都能在十秒内看懂你要表达什么。后续所有必做实验都可以复用这个模板。

3. 把必做实验拆开做：Beacon 帧、Probe 扫描与隐藏节点的抓包分析

环境就绪后，接下来是课程里最常安排的两块必做实验：一类是和 AP 发现、连接相关的过程抓包，另一类是信道竞争机制里的隐藏节点实验。这两块做完，基本覆盖了报告的主干。

3.1 抓 Beacon 与 Probe 两类管理帧：先拿到「空气里最响」的两种信号

Beacon 是 AP 周期性广播的信标帧，默认每 100 TU（1 TU = 1024 微秒，也就是约 102.4 毫秒）发一次。因为它是周期广播，不需要终端配合，是第一个要抓的帧。抓到 Beacon 后在 Wireshark 里能直接看到 SSID、支持的速率、能力信息（是否支持 802.11n/ac、是否开启 WPA）等字段。除了这些展示信息，Beacon 的两个数值字段是报告里最常见的分析点：wlan.beacon.interval表示信标间隔（单位 TU），wlan.fixed.timestamp是 AP 的 64 位微秒级时钟。

先在目标信道上抓一段连续 Beacon：

# 固定信道 6，抓到文件里，方便后面反复读 sudo airodump-ng wlan0mon --channel 6 --write beacon_test # Ctrl+C 结束后，用 tshark 抽出 Beacon 的关键字段 tshark -r beacon_test-01.cap \ -Y "wlan.fc.type_subtype == 0x08" \ -T fields \ -e frame.number -e frame.time_relative \ -e wlan.sa -e wlan.bssid \ -e wlan.beacon.interval -e wlan.ssid

运行后你会看到附近的 AP 每隔约 0.1 秒出现一行 Beacon。frame.time_relative这一列默认从抓包开始计时，相邻两行 Beacon 的时间差应该稳定在 102~104 毫秒左右；如果差值是 200 毫秒上下，说明这个 AP 被配置成了 200 TU 的信标间隔，或者你抓到了多个 AP 交错发出的 Beacon，需要先用wlan.bssid过滤出单一 BSS 再测。报告中写「本实验测得 BSSID 为 xx 的 AP 信标间隔为 102.4ms，与默认配置一致」，就比单纯贴截图完整得多。

注意：如果你的 airodump-ng 版本默认输出.pcapng后缀，把上面命令里的文件名改成实际生成的那个。

抓完 Beacon 后，让终端（手机或另一台无线设备）在实验现场关掉再打开 WiFi，Wireshark 里会出现一连串 Probe Request。终端并不知道附近有哪些 AP，所以会主动广播探测请求，携带自己希望连接的 SSID；AP 收到后会回应 Probe Response，携带自己的能力信息。过滤时用：Probe Request 是wlan.fc.type_subtype == 0x04，Probe Response 是wlan.fc.type_subtype == 0x05。

一个手机上同一分钟内发出多条 Probe，是因为终端会按频段和信道逐个扫描，每换一个信道就重发一次。这个现象本身就值得写进报告：它说明 WiFi 扫描不是「发一次等回复」，而是一个主动的、多轮次的信道扫描过程。这个实验不需要额外设备，手机开关一次 WiFi 就能复现，很适合作为必做实验的第一个数据点。

关联过程的四个阶段可以在这节一起分析：Authentication（0x0b）→ Association Request / Response，中间穿插 AP 的确认帧。在 Wireshark 里按wlan.fc.type_subtype == 0x0b过滤，能看到手机连上 AP 时的一次完整认证交互；之后连接建立。这一小段时序如果抓到了，报告的完整性立刻上一个档次。

3.2 隐藏节点与 DCF 退避：把 RTS 阈值当成开关做对比实验

隐藏节点是 CSMA/CA 机制绕不开的经典实验：A 和 C 都能连上 AP B，但 A 和 C 互相听不到对方的信号。A 向 B 发数据时，C 因为听不到 A 的传输而认为自己可以发，两个帧在 B 处碰撞，B 解调失败后收不到 ACK，发送方只能按退避机制重传。肉眼看到的指标就是吞吐率掉得很厉害、抓包里有大量重传。

搭建时至少要三台设备：一台当 AP B，一台当 STA A，一台当 STA C。A 和 C 放在 B 的两侧，距离拉开到互相收不到对方的 SSID 为止。判断标准不是「肉眼觉得远」，而是 A 上扫描不到 C 的热点（或信号强度低于 -90dBm），C 上也扫描不到 A 的热点；如果还能看到，继续拉远距离或把发射功率调低到 1dBm（部分驱动支持iw dev wlan0 set txpower 1）。这一步做不到位，后面所有数据都没有说服力。

先做对照组：关闭 RTS/CTS，让 A 和 C 同时向 B 灌流量。Linux 设置 RTS 阈值用：

# 阈值设为 2347 字节，几乎所有数据包都小于它，等同于关闭 RTS/CTS sudo iw dev wlan0 set rts 2347 # 阈值设为 256，包长超过 256 字节的数据帧会先发 RTS/CTS sudo iw dev wlan0 set rts 256

我一般用 iperf3 在 C 上向 A 打 UDP 流，跑 30 秒，抓一份 pcap；再切到开启 RTS 的配置，重跑一遍，抓第二份 pcap。两份 pcap 放在同一个 Wireshark 里对比。用下面的过滤器分别统计 RTS/CTS 帧数：

# 统计 RTS（0x1b）和 CTS（0x1c）的帧数 tshark -r hidden_node_rts_off.cap -Y "wlan.fc.type_subtype == 0x1b || wlan.fc.type_subtype == 0x1c" | wc -l tshark -r hidden_node_rts_on.cap -Y "wlan.fc.type_subtype == 0x1b || wlan.fc.type_subtype == 0x1c" | wc -l

管道到wc -l只是数行数，更精细的统计可以输出到 csv 再在表格软件里做透视。对照组里 RTS/CTS 数量接近 0，开启组里有几百甚至上千个，这个数字差异直接说明 RTS/CTS 机制确实被触发了。再用 iperf3 的最终报告（丢包率、抖动、带宽）做结果对比，报告里放一张表：

这个实验里最容易误导人的是只看吞吐率高低。隐藏节点环境下开启 RTS 后，吞吐率不一定比关闭时高很多，因为 RTS/CTS 本身也在占信道。正确的结论是「在存在隐藏节点的场景下，关闭 RTS 时碰撞导致的重传开销高于 RTS/CTS 的控制开销；排除碰撞因素后，整体吞吐更稳定」。写报告时把重传率、丢包率、平均时延三列数据摆出来，比一句「吞吐率提高」可信得多。

4. 无线实验最容易翻车的五个坑：现象、原因与解决办法

抓包实验的坑大多集中在「什么都抓不到」和「抓到但不会分析」两件事上。这五条是我见过最多的情况，每条按现象、原因、解决三部分写。

4.1 抓不到 Beacon/Probe：先查监控模式，再查信道

现象：Wireshark 开着，接口也选了，但列表里只有自己这台机器的少量帧，周围设备的 Beacon 一个都看不到。原因基本有三类：网卡还在 STA 模式；网卡在 monitor 模式但没有固定信道，1~13 信道跳频，Beacon 被漏掉；驱动对非本机管理帧做了过滤。解决：先跑iw dev wlan0mon info确认 type 是 monitor；再在 airodump-ng 里加上--channel 6固定信道；最后用另一台设备开关 WiFi 制造明确的 Probe Request，检验链路是否真的通了。如果三步都做了还是空，换一块 USB 无线网卡再试，多半是内置网卡驱动不支持。

4.2 同一台手机在抓包里出现多个 MAC：先关掉随机化再实验

现象：手机开关 WiFi 一次，抓包里出现好几个不同的源 MAC，Beacon/Probe 的来源对不上号。原因：现代手机默认开启 MAC 随机化，每次扫描或连接可能使用不同的 MAC。解决：在开发者选项或 WiFi 高级设置里找到「随机 MAC」选项，改回「使用设备 MAC」。做完这步再重新抓包，才能用 MAC 追踪同一设备的完整行为。另外这也提醒你：如果分析的是真实场景数据，看到同一终端多个 MAC 不是网卡坏了，是隐私机制在起作用，报告中可以将这一点作为背景说明。

4.3 隐藏节点实验反复复现不了：问题往往出在「A 能看到 C」

现象：A 和 C 分得很开，但跑流时吞吐率没有明显区别，碰撞也不明显。原因：A 和 C 其实还互相听得到信号，只是你主观认为「够远了」。解决：在 A 和 C 上各扫一次对方的热点，确认扫描列表里没有对方 SSID，或 RSSI 低于 -90dBm 后再开始。还要检查 RTS 阈值有没有真正生效：iw dev wlan0 get rts显示的值要和设置值一致；如果驱动不支持 RTS 阈值，就把实验挪到 AP 端做——用 hostapd 时在配置里写rts_threshold=256，对比 2347 两档分别抓包。选一台支持良好的网卡做 STA 端，能省掉很多调试时间。

4.4 每张截图下面只有图没有分析：用一张字段表换掉截图堆

现象：报告模板里每一页是「实验原理 → 抓包截图 → 无」。原因：不知道怎么把截图里的信息变成文字。解决：每张图下放一张五列表：「帧号、相对时间、源地址、目的地址、type_subtype、关键字段说明」。图只需要放关键一帧或关键时序段，其他帧用 tshark 抽成表格放正文，原始帧号供老师核对。例如 Beacon 分析里，「帧 1201，wlan.beacon.interval=100 TU，换算 102.4ms」比贴五张 Beacon 图有说服力。不要用整页截图凑字数，评分人看到表格就知道你理解字段含义。

4.5 选作实验直接把 pcap 塞进附录：数据量不等于工作量

现象：选作实验正文只有一段话，后面挂了一个上百 MB 的 pcap 附件。原因：误把原始数据量当工作量。解决：先按实验目标过滤出需要的子集，比如tshark -r 全部抓包.cap -Y "eapol || wlan.fc.type_subtype == 0x08" -w 选作_握手与信标.cap，把文件压到几 MB 级别；正文里所有结论都要指向具体的frame.number，而不是「见附件」。选作实验评的不是数据多，而是你有没有从原始数据里提出结论；每份过滤后的 pcap 都应该有一张对应的分析表。

5. 选作实验把报告写厚：EAPOL 握手分析与 NS3 仿真的两条路线

选作实验的目的是证明你能在必做实验之外多走一步。我最推荐的方向是抓一次 WPA2-Personal 的 EAPOL 四次握手：用 airodump-ng 监听目标 AP，等自己的手机关闭再打开 WiFi，完整握手就能抓到。过滤 eapol 字段后，报告里按 Message 1/2/3/4 拆开：前两步交换 ANonce 和 SNonce，双方各自派生出 PTK；第三步下发 GTK 并携带 MIC；第四步确认。如果看到 Message 2 的 MIC 校验失败，说明两端使用的 PSK 不一致，这是配置问题而不是网络问题。分析协议交互本身是安全的实验范畴，报告里不需要涉及任何口令获取的过程。

另一个加分路线是在 NS3 里把隐藏节点仿真重做一遍。用 WifiPhyHelper 搭三个节点，RtsCtsThreshold 设置成 0 和 500 两档，每档跑一次 UDP 流，用流量监控统计吞吐与丢包，和实物抓包互相印证。核心配置只有两行：

WifiMacHelper mac; mac.SetRtsCtsThreshold(500); // 0 表示关闭 RTS/CTS，500 表示超过 500 字节先发 RTS/CTS

仿真与实测互相对照后，报告结论就从「我看到的现象」升级成「不同机制下的规律」。我现在的习惯是动手抓包前先写半页白纸笔记：这组数据要证明什么、哪些字段能支持结论、参数记录在哪一栏。这样写出来的报告每一段都有落点，不会出现「图一堆、结论一句」的结构。希望这套流程对你有帮助，照着把必做实验跑一遍，再挑一个选作方向做深，这份实验报告就不再是凑页数了。

本文还有配套的精品资源，点击获取