c - Fixing extra 0 on the end of a filename request for tftp - warning: the comparison will always evaluate as ‘false’ for the p

admin管理员组

文章数量:1026989

I am trying to apply a patch that was posted a decade ago in the Asterisk forum, detailed here:

The problem is that the Cisco IP Communicator softphone software makes a bogus TFTP request for it's config file. As the poster said:

"I fired up Wireshark and got to the bottom of it. There is an extra 0x00 following the filename (or preceding the octet mode, depending on your point of view)"

I applied the recommended patch to tftp-hpa under Debian, the patch is here:

root@phony:~/src/debian/tftp-hpa-5.2+20150808/tftpd#  diff -u tftpd.c.orig tftpd.c
--- tftpd.c.orig        2024-11-16 09:37:52.572659519 -0800
+++ tftpd.c     2024-11-16 09:40:58.595989966 -0800
@@ -1096,6 +1096,11 @@
         }

         argn++;
+
+        /* begin Tad’s playing with the stupid zero that Cisco’s tfpd ignores */
+        if ( (cp+1) == 0) { ++cp;}
+        /* end Tad’s playing with the stupid zero that Cisco’s tfpd ignores */
+
         if (argn == 1) {
             mode = ++cp;
         } else if (argn == 2) {
root@phony:~/src/debian/tftp-hpa-5.2+20150808/tftpd#

I got a compiler error that states:

make[1]: Entering directory '/root/src/debian/tftp-hpa-5.2+20150808/tftpd'
x86_64-linux-gnu-gcc -g -O2 -W -Wall -Wpointer-arith -Wbad-function-cast -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wwrite-strings -Wundef -Wshadow -Wsign-compare -pipe -fno-strict-aliasing -I/root/src/debian/tftp-hpa-5.2+20150808 -c tftpd.c
tftpd.c: In function ‘tftp’:
tftpd.c:1101:21: warning: the comparison will always evaluate as ‘false’ for the pointer operand in ‘cp + 1’ must not be NULL [-Waddress]
 1101 |         if ( (cp+1) == 0) { ++cp;}
      |                     ^~

Needless to say, the patch does NOT work. However, if I change the line

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

to just

{ ++cp;}

then the patch DOES work - tftp skips over the extra 0x00 in the IP Communicator application's TFTP request, then the IP Communicator software loads it's config file and provisions the softphone, and I'm able to make and get calls with it using Asterisk.

(I'm using IP Communicator 8.6.6.0 which is the last version Cisco released. Needless to say, Cisco EOLed this softphone software many years ago. Comments from the peanut gallery about using Cisco's softphone with Asterisk instead of Cisco's UCM, or the general shoddiness of Cisco's programming, will be ignored)

Of course, this does mean now that the tftp server is useless for any other normal TFTP usage.

What I am curious about is the original patch poster's claim that it DID work - a decade ago, of course. I'm assuming that there was some change in C or C++ that back then the compiler made and assumption that made the code work, while now the complier no longer makes that assumption and the code breaks.

I'm not a C programmer but what I assume the mistake is, is instead of comparing the contents of the pointer to 0, it's comparing the pointer itself to 0, to decide whether or not to increment the pointer, and I was wondering how to fix this.

I am trying to apply a patch that was posted a decade ago in the Asterisk forum, detailed here:

The problem is that the Cisco IP Communicator softphone software makes a bogus TFTP request for it's config file. As the poster said:

"I fired up Wireshark and got to the bottom of it. There is an extra 0x00 following the filename (or preceding the octet mode, depending on your point of view)"

I applied the recommended patch to tftp-hpa under Debian, the patch is here:

root@phony:~/src/debian/tftp-hpa-5.2+20150808/tftpd#  diff -u tftpd.c.orig tftpd.c
--- tftpd.c.orig        2024-11-16 09:37:52.572659519 -0800
+++ tftpd.c     2024-11-16 09:40:58.595989966 -0800
@@ -1096,6 +1096,11 @@
         }

         argn++;
+
+        /* begin Tad’s playing with the stupid zero that Cisco’s tfpd ignores */
+        if ( (cp+1) == 0) { ++cp;}
+        /* end Tad’s playing with the stupid zero that Cisco’s tfpd ignores */
+
         if (argn == 1) {
             mode = ++cp;
         } else if (argn == 2) {
root@phony:~/src/debian/tftp-hpa-5.2+20150808/tftpd#

I got a compiler error that states:

make[1]: Entering directory '/root/src/debian/tftp-hpa-5.2+20150808/tftpd'
x86_64-linux-gnu-gcc -g -O2 -W -Wall -Wpointer-arith -Wbad-function-cast -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wwrite-strings -Wundef -Wshadow -Wsign-compare -pipe -fno-strict-aliasing -I/root/src/debian/tftp-hpa-5.2+20150808 -c tftpd.c
tftpd.c: In function ‘tftp’:
tftpd.c:1101:21: warning: the comparison will always evaluate as ‘false’ for the pointer operand in ‘cp + 1’ must not be NULL [-Waddress]
 1101 |         if ( (cp+1) == 0) { ++cp;}
      |                     ^~

Needless to say, the patch does NOT work. However, if I change the line

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

to just

{ ++cp;}

then the patch DOES work - tftp skips over the extra 0x00 in the IP Communicator application's TFTP request, then the IP Communicator software loads it's config file and provisions the softphone, and I'm able to make and get calls with it using Asterisk.

(I'm using IP Communicator 8.6.6.0 which is the last version Cisco released. Needless to say, Cisco EOLed this softphone software many years ago. Comments from the peanut gallery about using Cisco's softphone with Asterisk instead of Cisco's UCM, or the general shoddiness of Cisco's programming, will be ignored)

Of course, this does mean now that the tftp server is useless for any other normal TFTP usage.

What I am curious about is the original patch poster's claim that it DID work - a decade ago, of course. I'm assuming that there was some change in C or C++ that back then the compiler made and assumption that made the code work, while now the complier no longer makes that assumption and the code breaks.

I'm not a C programmer but what I assume the mistake is, is instead of comparing the contents of the pointer to 0, it's comparing the pointer itself to 0, to decide whether or not to increment the pointer, and I was wondering how to fix this.

本文标签：