修复tftp-hpa处理Cisco IP Communicator带额外0x00的TFTP请求时的编译警告与逻辑问题

我来帮你彻底解决这个问题，先把前因后果和修复逻辑理清楚：

你遇到的核心问题是Cisco IP Communicator（8.6.6.0版本，最后一个官方发布版）会发送格式异常的TFTP请求——它会在配置文件名的结束符0x00后面多带一个额外的0x00字节，导致标准tftp-hpa无法正确解析后续的模式参数。

原补丁的问题所在 #

十年前论坛里的那个补丁代码存在明显的逻辑错误：

if ( (cp+1) == 0) { ++cp;}

这里的cp是一个指针，cp+1是指针的地址值加1，和0比较永远是false（除非是空指针，但这里cp指向的是TFTP请求的数据包内容，不可能是空）。现在的编译器会严格检测这种无效判断并抛出警告，而且这段代码根本不会执行++cp的操作，自然起不到修复作用。

至于当年原作者说它能工作，大概率是笔误——要么他实际测试时直接写了++cp，要么当时的编译器没检测出这个错误，或者代码上下文和现在的tftp-hpa版本不同，但本质上这个判断逻辑是完全错误的。

正确的修复方案 #

你发现直接写{ ++cp;}能解决Cisco的问题，但代价是破坏了正常TFTP请求的处理——因为不管有没有额外的0x00，都会跳过一个字节。我们需要做的是只在确实存在额外0x00的时候才跳过它：

把原补丁的错误代码替换成以下内容：

/* 跳过Cisco IP Communicator请求中额外的0x00字节 */
if (*cp == 0) {
    ++cp;
}

这里的*cp是取指针cp指向的字节内容，判断是否为0x00。只有当当前位置确实是额外的空字节时，才执行++cp跳过它，完全不影响正常的TFTP请求解析。

修复后的效果 #

修改后重新编译tftp-hpa：

• 对于Cisco IP Communicator的异常请求：处理完文件名后，cp指向额外的0x00，判断成立，跳过该字节，接着正常解析模式参数，软phone就能成功获取配置文件。
• 对于正常的TFTP请求：处理完文件名后，cp直接指向模式字符串的起始字符（不是0x00），判断不成立，直接进入后续逻辑，服务器依然能正常服务其他设备。

验证步骤 #

1. 替换补丁代码为上述正确版本
2. 重新编译安装tftp-hpa：

   make clean && make && make install
   

3. 测试Cisco IP Communicator的配置获取，同时用其他正常设备测试TFTP服务，确认两者都能正常工作。

备注：内容来源于stack exchange，提问作者Ted Mittelstaedt