简介本资源是北京航空航天大学研究生《计算机网络》课程的实验三完整报告聚焦ARP协议原理与跨网段通信机制适用于高校网络课程学习者、备考学生及网络技术初学者。报告通过Wireshark抓包分析系统呈现ARP请求/应答交互过程、ARP缓存作用、报文字段结构Opcode、Sender/Target IP/MAC等并对比同网段与跨网段场景下ARP行为差异辅以默认网关配置验证和ICMP报文类型解析强化理论与实操结合。资源为单个PDF文件大小仅40KB内容精炼、图表与填表记录齐全便于快速查阅与复现实验。目前已有111人下载学习适合用于课后巩固、实验预习、网络协议理解深化及Wireshark工具入门实践。1. 北航研究生计算机网络实验一份能跑通ARPICMP全流程的Wireshark实战手记这不是一份“抄完交差就扔”的实验报告PDF而是一份带完整报文上下文、可复现抓包路径、含真实设备交互逻辑的网络层实操笔记。我去年带三届本科生重跑过这份实验——从VMware虚拟机配IP、双网卡桥接、GNS3路由器互联到Wireshark过滤表达式逐帧比对所有步骤都踩过坑、改过参数、验证过字段值。它解决的不是“ARP是什么”而是“为什么我的Wireshark里看不到Opcode2的应答”“为什么跨网段ping时Target MAC总是网关的而不是目标主机的”“为什么ICMP时间戳报文的Originate timestamp全是0”这类真正在实验室里让人抓耳挠腮的问题。适合正在准备计算机网络期末、408统考、或刚接手网络运维岗需要补底层协议理解的工程师。如果你手头只有Wireshark两台Windows虚拟机一个能配静态路由的路由器甚至用Windows自带的路由功能凑合这份实验就能跑通——它不依赖特定硬件但极度依赖对报文字段含义的精准解读。2. ARP协议深度拆解从广播请求到缓存命中每一步都对应真实报文字段2.1 为什么ARP请求必须是广播——链路层Destination字段的硬约束ARP工作在数据链路层与网络层之间其根本任务是解决“已知IP未知MAC”问题。当主机A192.168.1.22要向主机B192.168.1.21发ICMP Echo Request时它先查本地ARP缓存arp -a | findstr 192.168.1.21若无结果即No ARP Entries Found则构造ARP请求报文。关键点在于此时主机A根本不知道主机B的MAC地址因此无法单播发送。链路层Destination字段必须填全F广播地址ff:ff:ff:ff:ff:ff确保同一物理网段内所有设备都能收到。Wireshark中选中该报文在Ethernet II协议树下展开可见Destination: Broadcast (ff:ff:ff:ff:ff:ff) Source: VMware_2f:e3:85 (00:0c:29:2f:e3:85) Type: ARP (0x0806)提示不要试图用arp -s手动添加静态条目来跳过这步——实验要求观察动态学习过程硬塞静态条目会直接绕过广播请求导致后续分析失真。2.2 Opcode字段的两种取值request与reply的本质差异ARP报文结构中Hardware Type以太网为1、Protocol TypeIPv4为0x0800、HLEN6字节、PLEN4字节均为固定值真正驱动交互的是Opcode字段Opcode 1ARP Request表示“谁有192.168.1.21的MAC请告诉我”此时Target MAC Address字段强制置零00:00:00:00:00:00因为发起方根本不知道目标MACOpcode 2ARP Reply表示“我是192.168.1.21我的MAC是00:0c:29:99:cb:04”此时Target MAC Address被填入请求方的MAC即00:0c:29:2f:e3:85且报文变为单播Destination字段不再是广播。在Wireshark中对比两条报文Request报文的ARP协议树下Opcode: request (1)Reply报文则显示Opcode: reply (2)。注意Reply报文的Ethernet II层Destination已变为请求方MAC这是协议强制要求——避免广播风暴。2.3 ARP缓存的生命周期与刷新机制为什么第二次ping不再触发ARP请求实验报告中明确指出“ping1-学号”截获报文少了ARP报文原因正是ARP缓存生效。Windows默认ARP缓存超时时间为2分钟Linux为30秒可通过以下命令验证# 查看当前ARP缓存PowerShell Get-NetNeighbor | Where-Object {$_.IPAddress -eq 192.168.1.21} | Format-List # 输出示例 # LinkLayerAddress : 00-0C-29-99-CB-04 # State : Reachable # Lifetime : 00:01:58 # 剩余存活时间当缓存状态为Reachable时系统直接使用缓存中的MAC地址封装以太网帧跳过ARP请求流程。若想强制刷新缓存观察新请求执行arp -d 192.168.1.21 # 删除指定条目 # 或清空全部 arp -a -d注意arp -d后立即pingWireshark必捕获到新的ARP Request/Reply对——这是验证缓存机制最直接的方法。2.4 跨网段ARP的玄学为什么Target IP是网关而非目标主机实验2.6.2中PC A192.168.1.22ping PC B192.168.2.10时ARP请求的目标IP是192.168.1.10PC A的默认网关而非192.168.2.10。这是因为主机路由决策发生在IP层PC A查路由表发现192.168.2.10不在直连网段192.168.1.0/24必须转发给默认网关因此ICMP Echo Request的IP层Destination是192.168.2.10但数据链路层Destination必须是网关的MAC——所以ARP请求的对象是网关IP192.168.1.10网关路由器S1收到后根据自身路由表将报文转发至192.168.2.0/24网段并在该网段重新发起ARP请求获取PC B的MAC。Wireshark中可清晰看到ARP Reply的Sender IP Address是192.168.1.10网关Sender MAC Address是网关接口MAC如3c:e5:a6:45:6b:bc而非PC B的MAC。这是理解三层转发的关键分水岭。3. ICMP协议实战解析从Echo到Timestamp字段级对照Wireshark原始数据3.1 Echo Request/Reply报文Type字段决定报文类型Identifier/Sequence保证成对匹配实验中ping产生8个ICMP报文Wireshark过滤条件为icmp展开ICMP协议树可见报文序号Type字段值含义Code字段关键字段作用1,3,5,78Echo Request0Identifier(BE)和Sequence number(BE)共同标识本次ping会话2,4,6,80Echo Reply0Identifier和Sequence number与对应Request完全一致重点说明Identifier和Sequence numberIdentifier(BE)大端序为0x0a00即十进制2560Identifier(LE)小端序为0x000a即10——这是同一数值的不同字节序表示Sequence number(BE)为0x0100256Sequence number(LE)为0x00011Wireshark自动将BE值作为主显示但底层协议要求收发双方按相同字节序解析。若用Python scapy构造自定义ICMP包必须显式指定byteorderbig或little。验证方法在Wireshark中右键任一Request报文 →Follow → ICMP Stream可直观看到Request与Reply的Identifier/Sequence严格配对。3.2 Address Mask Request/Reply已被弃用但仍是理解ICMP扩展性的经典案例实验7中pingtest程序发送Type17的地址掩码请求Wireshark显示Request报文Address mask字段为0.0.0.0全零表示“请告知我的子网掩码”Reply报文Address mask为255.255.255.0即0xffffff00与PC A的IPv4配置一致。虽然现代操作系统已基本弃用该功能DHCP或手动配置更可靠但其结构揭示了ICMP的扩展设计思想Type17/18专用于地址掩码协商Code恒为0Checksum字段需校验整个ICMP报文含IP首部伪首部实验中0xe3ff与0xe3fe的微小差异源于Reply报文的Address mask字段值变化证明校验和实时计算有效。提示若Reply报文Checksum显示[incorrect]说明Wireshark未正确解析伪首部——需在Edit → Preferences → Protocols → IPv4中勾选Validate the IPv4 checksum if possible。3.3 Timestamp Request/Reply时间戳字段的“零值陷阱”与UTC基准实验8中时间戳报文的Originate timestamp、Receive timestamp、Transmit timestamp均显示为0 seconds after midnight UTC这并非错误而是pingtest程序未实现时间戳填充逻辑的典型表现。标准RFC 792规定Originate timestamp发送方记录报文生成时刻毫秒级UTCReceive timestamp接收方记录收到报文时刻Transmit timestamp接收方记录发出Reply时刻。真实环境中如用hping3发送这三个字段应有显著差异。例如hping3 -C 13 -E 13 -p 80 192.168.1.21 # 发送Timestamp RequestWireshark中可见Originate timestamp为非零值如1712345678.123而实验报告中全为0恰恰说明pingtest是教学简化版——它只构造报文框架不填充时间戳。这是理解协议规范与实际工具实现差距的重要案例。3.4 ICMP差错报文Destination Unreachable与Time Exceeded的封装结构实验9-10中两类关键差错报文Destination UnreachableType3, Code0当S1路由器无10.1.4.10路由时返回其ICMP载荷中嵌套了原始Echo Request的IP首部前8字节ICMP数据即IdentifierSequence用于源主机定位出错报文Time ExceededType11, Code0tracert利用TTL递减机制每经过一跳路由器TTL减1归零时返回该报文载荷同样封装原始Echo Request的IPICMP头部。在Wireshark中展开差错报文的Internet Control Message Protocol→Internet Protocol→Internet Control Message Protocol可见嵌套结构。这是ICMP差错报文的设计精髓不新建会话而是复用原报文上下文定位问题。4. Wireshark抓包实战从环境搭建到过滤表达式避开90%新手翻车点4.1 虚拟机网络拓扑配置VMware桥接模式下的IP与网关设置实验要求PC A与PC B位于不同网段如192.168.1.0/24与192.168.2.0/24需通过路由器S1互通。在VMware Workstation中PC A虚拟机网络适配器设为BridgedIPv4地址192.168.1.22子网掩码255.255.255.0默认网关填192.168.1.10S1的e0/1接口IPPC B虚拟机同设BridgedIPv4地址192.168.2.10子网掩码255.255.255.0默认网关填192.168.2.10S1的e0/2接口IPS1路由器需启用IP路由功能Windows Server可用netsh interface ipv4 set interface Ethernet forwardingenabled。注意若用GNS3模拟路由器务必关闭ip routing的默认关闭状态否则S1仅作二层交换机无法转发跨网段报文。4.2 Wireshark启动与过滤精准捕获ARP/ICMP避免海量无关流量启动Wireshark前先确定监听网卡PC A上运行ipconfig找到对应192.168.1.22的网卡名称如以太网在Wireshark中选择该网卡点击捕获按钮。关键过滤表达式Capture Filter影响抓包性能arp or icmp显示过滤表达式Display Filter不影响抓包仅筛选显示查看ARP交互arp查看ICMP Echoicmp.type 8 || icmp.type 0查看跨网段ARParp.dst.proto_ipv4 192.168.1.10查看差错报文icmp.type 3 || icmp.type 11提示Capture Filter在抓包前设置能极大减少CPU占用Display Filter在抓包后使用支持复杂逻辑。新手常混淆二者导致Wireshark卡死。4.3 报文导出与比对用Excel表格固化实验结论实验报告要求填写多张表格如ARP请求/应答字段对比手动录入易出错。推荐自动化方案Wireshark中选中目标报文 → 右键Export Packet Dissections → As CSV...用Python pandas读取CSV提取关键字段import pandas as pd df pd.read_csv(arp_packets.csv) # 提取ARP字段 arp_fields df[df[Protocol] ARP][[No., Source, Destination, Info]] print(arp_fields.to_string(indexFalse))将输出粘贴至Excel用条件格式高亮Opcode1与Opcode2行直观比对字段差异。此法避免手误且可复用脚本批量处理多组实验数据。4.4 常见问题排查血泪经验总结的5个致命坑现象1Wireshark捕获不到任何ARP报文arp -a显示缓存为空原因PC A与PC B不在同一物理网段但VMware网络适配器未正确桥接到宿主机物理网卡导致虚拟机间通信走NAT而非桥接。解决在VMware设置中确认网络适配器为Bridged并勾选Replicate physical network connection state若宿主机WiFi不稳定改用有线网卡桥接。现象2跨网段ping通但Wireshark只看到PC A发往网关的ARP看不到网关发往PC B的ARP原因Wireshark仅在PC A网卡捕获而网关到PC B的ARP发生在另一物理网段192.168.2.0/24需在PC B或S1上抓包。解决在PC B上同步启动Wireshark过滤arp arp.dst.proto_ipv4 192.168.2.10即可捕获网关发起的ARP请求。现象3ICMP Reply报文的Identifier与Request不一致原因pingtest程序每次运行生成随机Identifier而实验要求连续两次ping使用相同Identifier如ping -i 1000 -n 1 192.168.1.21中-i指定间隔但Identifier仍可能变。解决改用hping3固定Identifierhping3 -c 1 -i 1 --icmp --icmp-type 8 --icmp-ident 2560 --icmp-seq 1 192.168.1.21现象4tracert返回的TTL超时报文Wireshark中Time-to-live exceeded显示为[Malformed Packet]原因Wireshark版本过低3.2对IPv4分片报文解析异常或捕获时启用了Promiscuous mode导致混杂模式干扰。解决升级Wireshark至最新稳定版如3.6.16并在捕获选项中取消勾选Enable promiscuous mode。现象5ARP Reply报文中Target MAC Address显示为00:00:00:00:00:00而非目标MAC原因Wireshark解析ARP协议时将Reply报文的Target MAC字段误读为Request报文的占位符因RFC未强制要求Reply填Target MAC但实现中必须填。解决手动检查Ethernet II层Destination字段——它才是真正的目标MAC。Wireshark的ARP解析树存在显示bug以链路层字段为准。5. 实验进阶技巧用Python自动化验证ARP缓存刷新与ICMP字段一致性5.1 自动化ARP缓存状态监控实时检测Reachable超时手动执行arp -a再肉眼找Lifetime太低效。用Python调用Windows API获取精确缓存状态import subprocess import re from datetime import datetime, timedelta def get_arp_entry(ip): 获取指定IP的ARP缓存条目及剩余寿命 try: result subprocess.run([arp, -a, ip], capture_outputTrue, textTrue, checkTrue) lines result.stdout.strip().split(\n) for line in lines: if ip in line and dynamic in line: # 解析Lifetime: 00:01:58 lifetime_match re.search(rLifetime\s*:\s*(\d{2}:\d{2}:\d{2}), line) if lifetime_match: hms lifetime_match.group(1).split(:) remaining timedelta(hoursint(hms[0]), minutesint(hms[1]), secondsint(hms[2])) return { mac: line.split()[1], state: Reachable, remaining: remaining } return None except subprocess.CalledProcessError: return None # 监控循环 target_ip 192.168.1.21 while True: entry get_arp_entry(target_ip) if entry and entry[remaining] timedelta(seconds10): print(f[{datetime.now()}] ARP缓存即将过期剩余{entry[remaining]}触发刷新...) subprocess.run([arp, -d, target_ip]) # 立即ping触发新ARP subprocess.run([ping, -n, 1, target_ip]) else: print(f[{datetime.now()}] 缓存正常剩余{entry[remaining] if entry else N/A}) time.sleep(5)此脚本每5秒检查一次缓存剩余时间低于10秒时自动删除并触发新ARP——比人工操作更精准且可记录日志分析缓存波动规律。5.2 ICMP报文字段一致性校验用Scapy构造并比对原始字节实验报告要求比对Request/Reply字段但手动核对易漏。用Scapy生成标准报文导出原始字节与Wireshark捕获对比from scapy.all import * import binascii # 构造标准Echo Request pkt IP(dst192.168.1.21)/ICMP(type8, code0, id2560, seq1)/Hello # 获取原始字节 raw_bytes bytes(pkt) print(Echo Request原始字节十六进制:) print(binascii.hexlify(raw_bytes).decode()) # 构造Reply需修改IP层src/dst及ICMP type reply_pkt IP(src192.168.1.21, dst192.168.1.22)/ICMP(type0, code0, id2560, seq1)/Hello reply_bytes bytes(reply_pkt) print(\nEcho Reply原始字节十六进制:) print(binascii.hexlify(reply_bytes).decode())将输出十六进制字符串复制到Wireshark的Hex Dump面板用CtrlF搜索对应字段如0a00为Identifier BE值可100%确认字段位置与值——这是协议逆向分析的基石技能。5.3 Wireshark过滤表达式调试用布尔逻辑组合多条件实验中需同时满足“ARP报文”“Opcode2”“Target IP为192.168.1.21”单一过滤不够。组合表达式arp arp.opcode 2 arp.dst.proto_ipv4 192.168.1.21更进一步排除广播ARP只看单播Replyarp arp.opcode 2 arp.dst.proto_ipv4 192.168.1.21 !eth.dst ff:ff:ff:ff:ff:ffWireshark支持与、||或、!非、等于、!不等于等运算符合理组合可精准定位任意报文特征。5.4 实验报告表格自动化生成PandasLaTeX输出专业文档手绘表格易错且不美观。用Python生成LaTeX表格import pandas as pd # 定义ARP字段对比数据 data { 字段项: [链路层 Destination项, 链路层 Source项, 网络层Sender MAC Address, 网络层Sender IP Address, 网络层Target MAC Address, 网络层Target IP Address], ARP 请求数据报文: [Broadcast(ff:ff:ff:ff:ff:ff), Vmware_2f:e3:85(00:0c:29:2f:e3:85), Vmware_2f:e3:85(00:0c:29:2f:e3:85), 192.168.1.22(192.168.1.22), 00:00:00_00:00:00(00:00:00:00:00:00), 192.168.1.21(192.168.1.21)], ARP 应答数据报文: [Vmware_99:cb:04(00:0c:29:99:cb:04), Vmware_99:cb:04(00:0c:29:99:cb:04), Vmware_99:cb:04(00:0c:29:99:cb:04), 192.168.1.21(192.168.1.21), Vmware_2f:e3:85(00:0c:29:2f:e3:85), 192.168.1.22(192.168.1.22)] } df pd.DataFrame(data) # 导出为LaTeX表格 latex_table df.to_latex(indexFalse, escapeFalse, column_format|l|l|l|) print(latex_table)输出可直接粘贴至Overleaf编译生成符合学术规范的表格——从此告别手绘表格的像素级对齐噩梦。从那以后我每次做网络协议实验都强制走一遍ARP缓存监控脚本Scapy字段校验哪怕只是验证一个简单ping。因为协议细节藏在字节里而人眼会疲劳机器不会。希望帮到你。本文还有配套的精品资源点击获取
