估计http服务是挂载别人的。他的核心不是这个。再说使用者觉得不好用，换其他的就好，也不会反馈给他。

好的   2.10版也不行的  发过邮件联系过作者，他不认为是个问题

2011yaya2007777 发表于 2025-9-9 07:23
有些建议很好，待仔细研究。
关于断点续传的使用，你有些误解。正常情况下并不使用它，只有发生传输状况 ...

dhcpsrv2.5.2是免费的最高版本，收费版都2.10了，可能都已经改进了。个别的软件缺陷无需适应吧？

AI回答的  不知有没有帮助  不会编译没有测试。

有些建议很好，待仔细研究。
关于断点续传的使用，你有些误解。正常情况下并不使用它，只有发生传输状况时才使用。这时一般是整体重新传输（只重新尝试3次，大概率彻底失败）。如果可以断点续传，则从出错的地方续传即可。

我这里测试，永远是只读一次。
对于dhcpsrv2.5.2自带(dhcpsrv) ，当执行HEAD操作获得文件尺寸时，它返回0。旧版本直接退出，新版本则执行READ操作替代它，所以多读了一次。当然可以再改进，但是对于出现如此严重错误的程序，不值得下功夫。估计人家后续版本也根正了。

优化错误。“http_buffer_size = 0x10000; // 64KB缓冲区，提高传输性能” 没有意义。

grub_size_t read_size = len;
    if (read_size > http_buffer_size)
      read_size = http_buffer_size;


这里的len通常情况远大于0x10000。

根据您提供的 grub4dos for UEFI 中 PXE 启动相关的源代码， fsys_pxe.c 中关于 HTTP 协议的处理部分，我们可以分析出为什么在某些 HTTP 服务器上会出现需要下载两次文件（如 winpe.wim）才能启动的问题，以及为什么 HTTP 传输速度可能不够理想。

🔍 问题分析
1. 重复下载问题（下载两次）
在 http_read 函数中，存在一个 repeat 标签和 goto repeat 的逻辑，用于处理断点续传（Range 请求）。当发生以下情况时，会重新发起带 Range 头的请求：

c
if (status == GRUB_EFI_CONNECTION_FIN) {
  // ... 重新构造 Range 头，goto repeat
}
这意味着：

如果服务器不支持 Range 请求或响应异常（如连接提前关闭），代码会尝试重新下载；

在某些服务器（如 TinyPXEServer 或 Indy-based 服务器）中，Range 处理不规范，导致客户端必须发起多次请求才能完成下载；

尤其是在 headeronly=1（只读头部）和后续实际读取时，可能触发两次请求。

2. 传输速度慢
可能的原因包括：

小缓冲区读取：每次读取的缓冲区大小可能较小（如 1460 字节），导致频繁的网络往返；

服务器响应慢：某些服务器（如 TinyPXEServer）的 HTTP 实现效率较低；

UEFI HTTP 协议栈限制：UEFI 下的 HTTP 驱动可能没有优化大文件传输；

网络延迟：PXE 启动通常在局域网，但若服务器响应慢或网络拥堵也会影响速度。

🛠 解决方案建议
1. 避免重复下载
可以在 http_open 中增加对服务器 Range 支持能力的检测，若服务器明确不支持 Range，则禁用断点续传逻辑：

c
// 在 efihttp_request 中检测服务器是否支持 Range
if (response_data.status_code != GRUB_EFI_HTTP_STATUS_206_PARTIAL_CONTENT) {
  partial_content = 0; // 禁用断点续传
}
2. 优化传输性能
增大读取缓冲区：在 http_read 中适当增大 len（如 64KB~1MB），减少读写次数；

使用 TFTP 作为备选：若 HTTP 性能差，可回退到 TFTP：

c
if (cur_pxe_type == 1 && performance_test_failed) {
  cur_pxe_type = 0; // 切换到 TFTP
  goto only_tftp;
}
启用压缩传输：若服务器支持 Accept-Encoding: gzip，可尝试启用（需服务器支持）；

3. 服务器兼容性处理
对不支持 Range 的服务器（如某些嵌入式 HTTP 服务），禁用 partial_content；

对已知有问题的服务器（如 TinyPXEServer），使用 TFTP 代替 HTTP；


附件主要优化内容

• 服务器能力检测：新增了 detect_server_capabilities() 函数，用于检测服务器是否支持 Range 请求和 Keep-Alive 连接
• 缓冲区大小优化：增加了 http_buffer_size 变量，将 HTTP 读取缓冲区从默认大小增加到 64KB，显著提高传输性能
• 重试机制：为 HTTP 请求和读取添加了重试机制，最多重试 3 次，提高网络不稳定的容错性
• 超时处理：为所有网络操作添加了超时计数器，避免无限等待
• 连接管理：根据服务器能力动态设置 Connection 头，支持 Keep-Alive 的服务器会保持连接，提高性能
• Range 请求优化：只有在服务器明确支持 Range 请求时才使用断点续传功能
• 错误处理改进：增强了错误处理和日志输出，便于调试网络问题
  
  

AI回答的  不知有没有帮助  不会编译没有测试。

xiaoy 发表于 2025-9-5 18:13
希望葱大继续修正让G4E通过一些HTTP服务（https://www.dhcpserver.de/cms/）启动PE 不要下载两次的问题  ...

网启对http要求很严，很多http服务器不支持ipxe的sanboot，估计这个问题和sanboot要求一样

希望葱大继续修正让G4E通过一些HTTP服务（https://www.dhcpserver.de/cms/）启动PE 不要下载两次的问题

这是你使用的HTTP服务有缺陷，我在常用HTTP服务比较一文中已经详细说明。你换一个再看看。如果有问题再反馈。反馈时说明使用了什么HTTP服务。

江南一根葱 发表于 2025-9-5 12:30
@2011yaya2007777

精修化改了下，新的源码我已经让ai改好了，测试没问题

希望葱大继续修正让G4E通过一些HTTP服务（https://www.dhcpserver.de/cms/）启动PE 不要下载两次的问题 并且感觉HTTP速度并不快

@2011yaya2007777
grub4dos-for_UEFI.rar (1.22 MB, 下载次数: 13)

2025-9-5 12:30 上传

点击文件名下载附件
下载积分: 无忧币 -2

精修化改了下，新的源码我已经让ai改好了，测试没问题

江南一根葱 发表于 2025-9-4 22:57
又改了很多，我成功编译出来了，为了装逼自己发了个贴，你看看有没有参考价值
http://bbs.wuyou.net/for ...

验证了葱大的结果，ntboot方式在NBPXE与TINYPXE，在DHCP和PROXY两种模式下均HTTP成功启动到PE桌面。

PXE至少连续测试两次以上，我目前测试第一遍都是有问题的，特别是改变网启环境后。

2011yaya2007777 发表于 2025-9-4 19:40
经测试，无效。

1345 + if (pxe_mode->pxe_reply_received)  

又改了很多，我成功编译出来了，为了装逼自己发了个贴，你看看有没有参考价值
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=447486&extra=page%3D1&mobile=2

修复方案:

经测试，无效。

1345 + if (pxe_mode->pxe_reply_received)  
这个括号内的值，无论是在DHCP模式，还是在proxyDHCP模式，都为零。
因此无法修正。

正好学习一下

江南一根葱 发表于 2025-9-4 17:10
深度只支持传统bios
我让ai看了下g4e的源码，给出了这个信息，不知道有没有用
好的，我来检查一下 grub ...

活学活用，真NB！！！

非常好，辛苦了。过一会我修改一下看看。

2011yaya2007777 发表于 2025-8-29 16:02
经测试，可以正确分配IP地址，但是不能通讯。不知为何。

深度只支持传统bios
我让ai看了下g4e的源码，给出了这个信息，不知道有没有用
好的，我来检查一下 grub4dos for uefi 项目中关于 ProxyDHCP 的网络代码问题。

  根据你的描述，问题在于当设备通过 ProxyDHCP 启动时，程序未能正确捕获 TFTP 服务器的 IP
  地址，而是错误地使用了 DHCP 服务器的 IP 地址。这通常发生在处理 DHCP OFFER 数据包时，没有正确区分来自主
  DHCP 服务器和来自 ProxyDHCP 服务器的响应。

  我的计划如下：
   1. 定位代码：我将搜索项目源代码，特别是与 PXE/iPXE 和 DHCP 客户端逻辑相关的部分，查找处理 siaddr (Server IP
      Address) 字段或 DHCP Option 66 的代码。
   2. 分析问题：分析代码逻辑，确认它是否在收到多个 DHCP OFFER 时，错误地覆盖了正确的 TFTP 服务器地址。
   3. 实施修复：修改代码，确保一旦从 ProxyDHCP 响应中获取到有效的 TFTP 服务器地址后，就不会再被后续来自主 DHCP
      服务器的响应所覆盖。
   4. 记录过程：将问题分析和修复步骤详细写入 bug.txt 文件。

  现在，我将开始在 stage2 目录中搜索相关代码。
╭───────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✔ SearchText 'siaddr|dhcp|pxe|tftp' within stage2                                                │
│                                                                                                   │
│    Found 1005 matches                                                                             │
╰───────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ 好的，搜索结果非常清晰。问题集中在 fsys_pxe.c 文件中，该文件负责处理 UEFI PXE 启动的核心逻辑。

  问题分析:

  在 fsys_pxe.c 的 grub_efinet_findcards 函数中，我找到了以下代码块：

   1 struct grub_efi_pxe_mode *pxe_mode = pxe_entry->mode;//模式
   2 discover_reply = (BOOTPLAYER *)((char *)&pxe_mode->dhcp_ack.dhcpv4);//引导播放器
   3 pxe_sip = discover_reply->sip;          //服务器IP
   4 pxe_yip = discover_reply->yip;        //自己的IP

  这段代码的问题在于，它只从 dhcp_ack 包中获取服务器IP (pxe_sip)。在标准的 DHCP 流程中，这是正确的。但在
  ProxyDHCP 环境中，客户端会收到两个响应：
   1. 一个来自 DHCP 服务器的 DHCP ACK，提供客户端 IP 地址 (yip)。
   2. 一个来自 ProxyDHCP 服务器的 PXE Reply (或 Proxy Offer)，提供 TFTP 服务器 IP 地址 (sip) 和启动文件名。

  当前代码忽略了第二个包，因此 pxe_sip 被错误地设置为了 DHCP 服务器的 IP，而不是 TFTP 服务器的 IP。

  修复方案:

  我将修改这段代码，使其能够正确处理 ProxyDHCP 的情况。修改后的逻辑将是：
   1. 首先，从 dhcp_ack 包中获取客户端 IP (pxe_yip) 和默认的服务器 IP (pxe_sip)。
   2. 然后，检查 pxe_mode->pxe_reply_received 标志，判断是否存在来自 ProxyDHCP 服务器的响应。
   3. 如果存在，就从 pxe_reply 包中提取 sip，并用它覆盖 pxe_sip。这样就能确保在 ProxyDHCP 环境下使用正确的 TFTP
       服务器地址。

  我现在开始修改 fsys_pxe.c 文件。 Thank you for providing the file content. I can now see the exact text and whitespace, which will prevent the previous
  error.

  The block of code that needs to be replaced is:

   1   //从引导播放器获取IP地址
   2   struct grub_efi_pxe_mode *pxe_mode = pxe_entry->mode;//模式
   3   discover_reply = (BOOTPLAYER *)((char *)&pxe_mode->dhcp_ack.dhcpv4);//引导播放器
   4   pxe_sip = discover_reply->sip;        //服务器IP
   5   pxe_yip = discover_reply->yip;        //自己的IP
   6   station_ip = *(int*)pxe_mode->station_ip.v4;    //站IP
   7   subnet_mask = *(int*)pxe_mode->subnet_mask.v4;  //子网掩码

  I will now replace it with the corrected logic.
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✔ Edit stage2\fsys_pxe.c:   //从引导播放器获取IP地址... =>   //从引导播放器获取IP地址...                       │
│                                                                                                                 │
│    1342   discover_reply = (BOOTPLAYER *)((char *)&pxe_mode->dhcp_ack.dhcpv4);    //引导播放器                  │
│    1343   pxe_sip = discover_reply->sip;          //服务器IP                                                    │
│    1344   pxe_yip = discover_reply->yip;        //自己的IP                                                      │
│    1345 + if (pxe_mode->pxe_reply_received)                                                                     │
│    1346 + {                                                                                                     │
│    1347 +   discover_reply = (BOOTPLAYER *)((char *)&pxe_mode->pxe_reply.dhcpv4);                               │
│    1348 +   if (discover_reply->sip)                                                                            │
│    1349 +     pxe_sip = discover_reply->sip;                                                                    │
│    1350 + }                                                                                                     │
│    1351   station_ip = *(int*)pxe_mode->station_ip.v4;    //站IP                                                │
│    1352   subnet_mask = *(int*)pxe_mode->subnet_mask.v4;  //子网掩码                                            │
│    1353   printf_debug ("pxe_sip=%x, pxe_yip=%x\n",pxe_sip,pxe_yip);//901a8c0,b01a8c0                           │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────

Pxe启动可能是个坑，造成yaya大精力浪费。

2011yaya2007777 发表于 2025-8-29 16:02
经测试，可以正确分配IP地址，但是不能通讯。不知为何。

深度远程启动管理器试了，不会用。查深度论坛，也没内容，估计是软件太旧了。
还是用TINPXE，先搞定它的DHCP与代理两种模式就好了，目前好像只有代理模式有问题。其他几个没有代理模式。

蓝奏云下载链接 深度远程启动管理

经测试，可以正确分配IP地址，但是不能通讯。不知为何。

蓝奏云下载链接 深度远程启动管理器.zip - 蓝奏云 https://wweh.lanzouw.com/i9cVP33sgmeh

使用NBpxe_Serve作为服务器，G4E：DHCP模式获取的服务器IP地址是192.168.220.254，DHCP-Proxy模式获取的服务器地址为192.168.220.254。
使用TingPXE作为服务器，G4E：DHCP模式获取的服务器IP地址是192.168.220.1，DHCP-Proxy模式获取的服务器地址为192.168.220.254。
使用NBpxe_Serve作为服务器，IPXE.EFI：DHCP模式next-server地址是192.168..220.254，DHCP-Proxy模式next-server地址是192.168..220.254
使用TingPXE作为服务器，IPXE.EFI：DHCP模式next-server地址是192.168..220.1，DHCP-Proxy模式next-server地址是192.168..220.254

应该是 NBpxe_Server 的IP地址处理方式与TingPXE不一样。

2011yaya2007777 发表于 2025-8-26 20:54
pxe

DHCP与DHCP-proxy两种不同状态如图，均没有获取到192.168.220.1，所以都是获取不到菜单：

mygamexxx 发表于 2025-8-26 13:56
网络启动区葱大的NBpxe_Server测试，均无法获取菜单。

IPXE.EFI通过脚本解决，方法如下：

这个一直只有ipxe才有这样的设置

谢谢大佬的分享

pxe

2011yaya2007777 发表于 2025-8-26 14:13
G4E这方面比较弱，只能通过UEFI固件提供的PXE协议，获得服务器的IP地址。对于多个服务器提供若干IP地址，会 ...

G4E有没有查看IP地址的命令？

G4E这方面比较弱，只能通过UEFI固件提供的PXE协议，获得服务器的IP地址。对于多个服务器提供若干IP地址，会怎么选择，我也不知道，没有遇到过。

网络启动区葱大的NBpxe_Server测试，均无法获取菜单。

IPXE.EFI通过脚本解决，方法如下：
#判断是否存在DHCP代理
chain ${next-server}/menu.ipxe || set next-server ${proxydhcp/next-server}

在IPXE中，获取的初始next-server是192.168.220.254，proxydhcp/next-server是192.168.220.1
不知G4E是否有办法？

感谢分享，楼主辛苦了！

感谢分享，楼主辛苦了！