Syslinux - Mar 2010 - Making tftpd (hpa) firewall frienldy

Hello all,

 Tested on linux 2.6.18 (Centos5) and FreeBSD 7.0.

You would execute it like below (which basically makes tftp reply back with
same port is listening on )
tftpd --port-range 69:69 -4 -s /tftpboot/


--- tftp-hpa-0.49/tftpd/tftpd.c       2008-10-21 01:08:31.000000000 +0300
+++ tftp-hpa-0.49-tftpd-reuseport.c 2010-03-03 15:19:26.000000000 +0200
@@ -524,6 +524,11 @@
 #ifndef __CYGWIN__
             set_socket_nonblock(fd4, 1);
 #endif
+   { int x = 1; setsockopt (fd4, SOL_SOCKET, SO_REUSEADDR, &x, sizeof (x));
}
+#ifdef SO_REUSEPORT
+   { int x = 1; setsockopt (fd4, SOL_SOCKET, SO_REUSEPORT , &x, sizeof
(x)); }
+#endif
+
             memset(&bindaddr4, 0, sizeof bindaddr4);
             bindaddr4.sin_family = AF_INET;
             bindaddr4.sin_addr.s_addr = INADDR_ANY;
@@ -900,6 +905,14 @@
         syslog(LOG_ERR, "socket: %m");
         exit(EX_IOERR);
     }
+   { int x = 1; setsockopt (peer, SOL_SOCKET, SO_REUSEADDR, &x, sizeof
(x)); }
+#ifdef SO_REUSEPORT
+   { int x = 1; setsockopt (peer, SOL_SOCKET, SO_REUSEPORT , &x, sizeof
(x)); }
+#endif
+    if (pick_port_bind(peer, &myaddr, portrange_from, portrange_to) < 0)
{
+        syslog(LOG_ERR, "bind: %m");
+        exit(EX_IOERR);
+    }

     /* Set up the supplementary group access list if possible */
     /* /etc/group still need to be accessible at this point */
@@ -947,10 +960,6 @@
     }

     /* Process the request... */
-    if (pick_port_bind(peer, &myaddr, portrange_from, portrange_to) < 0)
{
-        syslog(LOG_ERR, "bind: %m");
-        exit(EX_IOERR);
-    }

     if (connect(peer, &from.sa, SOCKLEN(&from)) < 0) {
         syslog(LOG_ERR, "connect: %m");

--On Thursday, March 04, 2010 06:56:08 PM +0200 cgm mgc <999cgm at
gmail.com>
wrote:
> Hello all,
>
>  Tested on linux 2.6.18 (Centos5) and FreeBSD 7.0.
>
> You would execute it like below (which basically makes tftp reply back
> with same port is listening on )
> tftpd --port-range 69:69 -4 -s /tftpboot/
Did you test what happens if you compile with this option when you're _not_ 
trying to make all the traffic happen on the tftp port?  I'd expect it to 
break the port-selection algorithm some of the time.  For that matter, I 
would not expect the usage you describe to work well with multiple 
transfers going on at once.

If this is going to go in, I think it needs to be controlled by a runtime 
option.  A server that always had the behavior implemented by your patch 
would probably not be a good thing.

-- Jeff