网络启动

本节介绍如何在树莓派 3B，3B +和 2B v1.2上进行网络引导。在树莓派 4上，网络引导是在 EEPROM 的第二阶段引导程序中实现的。有关更多信息，请参见Pi 4 Bootloader配置页面。我们还有关于设置网络启动系统的教程。网络启动仅适用于以上树莓派型号中内置的有线适配器。不支持通过无线 LAN 引导，也不支持从任何其他有线网络设备引导。

要进行网络引导，引导 ROM 执行以下操作：

初始化板载以太网设备(Microchip LAN9500或 LAN7500 ) 发送 DHCP 请求 接收 DHCP 回复 (可选)接收 DHCP 代理回复 * ARP到 tftpboot 服务器 * ARP回复包括 tftpboot 服务器的以太网地址 * TFTP RRQ'bootcode.bin' 找不到文件：服务器以文本错误消息回复 TFTP 错误响应 文件存在：服务器将以文件的首个数据块(512字节)作为响应，并在标头中带有一个块号 * Pi回复包含块号的 TFTP ACK数据包，并重复直到最后一个不是 512 字节的块 * TFTP RRQ'bootsig.bin' *这通常会导致错误"找不到文件"。这是预料之中的，并且 TFTP 引导服务器应该能够处理它。

从这一点开始，bootcode.bin代码继续加载系统。它将尝试访问的第一个文件是[serial_number] /start.elf。如果这不会导致错误，则将要读取的任何其他文件都将前面带有" serial_number"。这很有用，因为它使您可以为 Pis 创建具有单独的 start .elf/kernels的单独目录要获取设备的序列号，您可以尝试使用这种启动模式，并查看使用 tcpdump /wireshark访问的文件，或者可以运行标准的树莓派 OS SD卡和" cat/proc/cpuinfo"。

如果将所有文件放入 tftp 目录的根目录，则将从该目录访问以下所有文件。

调试网络启动模式

首先要检查的是 OTP 位是否已正确编程。为此，您需要在 config .txt中添加" program_usb_boot_mode = 1"并重启(使用可正确引导到树莓派 OS中的标准 SD 卡)。完成此操作后，您应该可以执行以下操作：

$ vcgencmd otp_dump | grep 17：
17：3020000a

如果第 17 行包含该值，则说明已正确编程了 OTP 。现在，您应该能够卸下 SD 卡，插入以太网，然后在 Pi 上电后约 5 秒钟，以太网 LED 应点亮。

要捕获服务器上的以太网数据包，请在 tftpboot 服务器(或 DHCP 服务器，如果它们不同)上使用 tcpdump 。您将需要在此处捕获数据包，否则，因为网络交换机不是集线器，您将无法看到直接发送的数据包!

 sudo  tcpdump  -i eth0 -w dump.pcap

这会将所有内容从 eth0 写入文件 dump .pcap，然后可以对其进行后期处理或将其上传到 cloudhark .com进行通信

DHCP请求/回复

至少您应该看到 DHCP 请求和答复，如下所示：

6：44：38.717115 IP(tos 0x0，ttl 128，id 0，偏移量 0 ，标志[无]，原始 UDP (17)，长度 348 )
    0.0.0.0.68> 255.255.255.255.67：[no cksum] BOOTP/DHCP，来自 b8 ：27：eb：28：f6：6d的请求，长度 320 ，xid 0x26f30339，标志[无](0x0000)
客户端以太网地址 b8 ：27：eb：28：f6：6d
Vendor-rfc1048扩展
魔法饼干 0x63825363 
DHCP消息选项 53 ，长度 1 ：发现
参数请求选项 55 ，长度 12 ：
供应商选项，供应商类别，BF，选项 128 
选项 129 ，选项 130 ，选项 131 ，选项 132 
选项 133 ，选项 134 ，选项 135 ，TFTP
ARCH选项 93 ，长度 2 ：0
NDI选项 94 ，长度 3 ：1.2.1
GUID选项 97 ，长度 17 ：0.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68
供应商级选项 60 ，长度 32 ：" PXEClient：Arch：00000：UNDI：002001"
END选项 255 ，长度 0 
16：44：41.224619 IP(tos 0x0，ttl 64，id 57713，偏移量 0 ，标志[无]，原始 UDP (17)，长度 372 )
    192.168.1.1.67> 192.168.1.139.68：[udp sum ok] BOOTP/DHCP，答复，长度 344 ，xid 0x26f30339，标志[无](0x0000)
您的 IP  192.168.1.139
服务器 IP  192.168.1.1
客户端以太网地址 b8 ：27：eb：28：f6：6d
Vendor-rfc1048扩展
魔法饼干 0x63825363 
DHCP消息选项 53 ，长度 1 ：提供
服务器 ID 选项 54 ，长度 4 ：192.168.1.1
租赁时间选择 51 ，长度 4 ：43200
RN选项 58 ，长度 4 ：21600
RB选项 59 ，长度 4 ：37800
子网掩码选项 1 ，长度 4 ：255.255.255.0
BR选项 28 ，长度 4 ：192.168.1.255
供应商级选项 60 ，长度 9 ：" PXEClient"
GUID选项 97 ，长度 17 ：0.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68供应商选项选项 43 ，长度 32 ：6.1.3.10.4.0.80.88.69.9.20.0.0.17.82.97.115.112.98.101.114.114.121.32.80.105.32.66.111.111.116.255 END选项 255 ，长度 0

答复的重要部分是"供应商选项"选项 43 。尽管需要，该选项必须包含字符串" 树莓派 Boot"。对于引导 ROM 中的错误，您可能需要在字符串末尾添加三个空格。

TFTP文件读取

您将知道是否正确指定了供应商选项：如果指定了此选项，则将看到后续的 TFTP RRQ数据包正在发送。 RRQ可以由第一数据块或错误提示找不到文件来回复。在某些情况下，他们甚至收到第一个数据包，然后 Pi 终止传输(这在检查文件是否存在时发生)。以下示例仅是三个数据包：原始读取请求，第一个数据块(尽管最后一个块始终小于 512 字节，并且长度可能为零)，第一个数据块(始终为 516 个字节，包含一个标头和 512 个字节的数据)，以及第三个数据包(包含与数据块中的帧号相匹配的帧号的 ACK )。

16：44：41.224964 IP(tos 0x0，ttl 128，id 0，偏移量 0 ，标志[无]，原始 UDP (17)，长度 49 )
    192.168.1.139.49152> 192.168.1.1.69：[no cksum] 21 RRQ" bootcode.bin"八位字节
16：44：41.227223 IP(tos 0x0，ttl 64，id 57714，偏移量 0 ，标志[无]，原始 UDP (17)，长度 544 )
    192.168.1.1.55985> 192.168.1.139.49152：[udp sum ok] UDP，长度 516 
16：44：41.227418 IP(tos 0x0，ttl 128，id 0，偏移量 0 ，标志[无]，原始 UDP (17)，长度 32 )
    192.168.1.139.49152> 192.168.1.1.55985：[no cksum] UDP，长度 4

已知问题

以太网启动模式存在许多已知问题。由于引导模式的实现是在芯片本身中，因此除了将 SD 卡与 bootcode .bin文件一起使用外，没有其他解决方法。

DHCP尝试五次后超时

树莓派将尝试 DHCP 请求五次，两次间隔五秒，总共 25 秒。如果服务器此时无法响应，则 Pi 将进入低功耗状态。除了 SD 卡上的 bootcode .bin之外，没有其他解决方法。

不支持单独子网中的 TFTP 服务器

已在树莓派 3 Model B +(BCM2837B0)中修复。

DHCP中继损坏

DHCP检查还检查跳数是否为" 1"，而 DHCP 中继则不会。

已在树莓派 3 Model B +中修复。

树莓派引导字符串

由于计算字符串长度错误，DHCP回复中的" 树莓派 Boot"字符串需要额外的三个空格。

已在树莓派 3 Model B +中修复

DHCP UUID常数

DHCP UUID设置为恒定值。

已在树莓派 3 Model B +中修复；该值设置为 32 位序列号。

ARP检查在 TFTP 事务中可能无法响应

树莓派仅在处于初始化阶段时才响应 ARP 请求。一旦开始传输数据，它将无法继续响应。

已在树莓派 3 Model B +中修复。

DHCP请求/答复/确认顺序未正确实施

在启动时，树莓派广播 DHCPDISCOVER 数据包。 DHCP服务器回复 DHCPOFFER 数据包。然后，树莓派继续引导而不进行 DHCPREQUEST 或等待 DHCPACK 。这可能导致两个单独的设备被提供相同的 IP 地址并使用它，而没有正确地将其分配给客户端。

在这种情况下，不同的 DHCP 服务器具有不同的行为。 dnsmasq(取决于设置)将对 MAC 地址进行哈希处理以确定 IP 地址，然后对 IP 地址执行 ping 操作以确保其尚未使用。这减少了发生这种情况的机会，因为它要求哈希中发生冲突。

也可以看看： * 网络启动教程