This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] tftp-hpa 5.0


On 11/19/2010 4:54 AM, Gernot Hillier wrote:
> Now, we miss a s/5.0-1/5.0-3/ in the README. ;-) Or will the version
> number be reset upon final upload to cygwin.com? Why -3? See below (IPv6
> problems... :-( ).

What are you talking about?  The package I uploaded has:

----- version 5.0-2 -- 2010-11-16 -----
* Initial release for Cygwin 1.7.
* Revised cygwin README. Updated tftpd-config script messages.
* Enable IPv6.
* Enable pathname remapping.

----- version 5.0-1 -- 2010-10-nn -----
* Unreleased.

There is no 5.0-3.  I reset to 5.0-1 since I changed the name of the
package from your tftp-hpa- to tftp-  and tftp-server-.  I've made two
releases. 5.0-1 and 5.0-2.  I don't see where you are getting any
references to 5.0-3.

> And the first para of "Port Notes" is now obsolete since you added ipv6
> and remap support.

Good point.

> Apart from that, the README got even better now, I really like it! Will
> definitely help me to remember the privilege chaos background.

Good.

>>>   Perhaps you could also add a hint that the user might want to
>>>   change TFTPBOOT and args_value in the script before starting. Or
>>>   perhaps you could even make it interactive?
>>
>> Well...I think that's an advanced topic -- especially as the package, as
>> a *package*, assumes that /var/lib/tftpboot/ WILL be the directory
>> containing the files to be served.
> 
> That's no problem any more. I just noticed the "--args" argument to
> tftpd-config which is described and allows exactly what I needed. So you
> already fixed this for me. :-)

OK.

>> e.g. we already ensure that the directory is created, and included in
>> the tarball.  If somebody wants to *modify* the installation *after*
>> getting it running in its default mode, that's fine (e.g. by going to
>> the Service Manager and modifying the args that way, for standalone; or
>> editing /etc/inetd.d/tftp or /etc/xinetd.d/tftp).
> 
> Just for the sake of completeness: for standalone mode it's not that
> easy as you can't change the cygrunsrv parameters in the Service Manager
> - at least not for XP-64bit. So far, I found no easy way besides
> removing and reinstalling the service. That's exactly why I decided to
> instead modify tftpdir in tftpd-config.

Hmm.  I wonder if cygrunsrv ought to have a --modify function, to go
along with --install and --remove.

Well, the README also describes how to install manually using cygrunsrv,
so interested parties could do this;

   tftpd-config --standalone

to get everything (including the user accounts) set up, and then

   cygrunsrv -R tftpd
   cygrunsrv -I tftpd .... other args

to reinstall with their preferred args.  But...I don't think that really
needs to be documented as such.

>> I suggest:
>>
>>   1) test the binary in IPv4 mode.  e.g. drop it in place of your
>> current 5.0-1 tftpd.exe and make sure it still works with your inhouse
>> IPv4 clients without any trouble.
> 
> Unfortunately, the IPv6 support breaks things for me. tftpd doesn't
> start on my XP-64 box and says:
> 
> tftpd: PID xxxx: cannot open IPv6 socket, disable IPv6: Address family
>    not support by protocol
> tftpd: PID xxxx: Cannot set nonblock flag on socket: Bad file
>    descriptor.
> tftpd: PID xxxx: `tftpd` service stopped, exit status: 71

Well, that stinks.  Er...do you have IPv6 enabled at all?  It's not
enabled by default on Server2003 (and since XP64 is based on that kernel...)

Try this

   1. Go to Start | Control Panel, and double-click
      Network Connections.
   2. Right-click the network adapter on which you want
      to enable IPv6, and select Properties.
   3. Click Install.
   4. Select Protocol from the list of installation
      choices, and click Add.
   5. Select Microsoft TCP/IP Version 6, and click OK.

These instructions may be valid only on SP1 and above; I'm not sure.

Then, try to run tftpd again.  If it works, then what we need to fix is
to allow tftpd to work (in IPv4 mode) when IPv6 is not available. (*)
If it doesn't work...then we've got bigger problems.

To remove IPv6, do the same thing only click 'Uninstall' instead.

(*) The first bug is this (found by inspection):

--- tftpd.c.orig	2010-11-19 07:39:42.205800000 -0500
+++ tftpd.c	2010-11-19 07:40:26.229000000 -0500
@@ -591,11 +591,12 @@
                     syslog(LOG_ERR,
                            "cannot open IPv6 socket, disable IPv6: %m");
                 }
-            }
-            set_socket_nonblock(fd6, 1);
-            memset(&bindaddr6, 0, sizeof bindaddr6);
-            bindaddr6.sin6_family = AF_INET6;
-            bindaddr6.sin6_port = htons(IPPORT_TFTP);
+            } else {
+                set_socket_nonblock(fd6, 1);
+                memset(&bindaddr6, 0, sizeof bindaddr6);
+                bindaddr6.sin6_family = AF_INET6;
+                bindaddr6.sin6_port = htons(IPPORT_TFTP);
+	    }
         }
 #endif
         if (address) {


The problem is, in the IPv6 block (unlike the IPv4 block) it is possible
to reach set_socket_nonblock(fd6, ...) when fd6 is invalid -- because
you won't exit earlier when fd4 IS valid.  Whether this is enough to
allow tftpd to keep working (in IPv4 mode) when IPv6 is unavailable, I
don't know -- but to test that, you may need to uninstall IPv6 support
if you installed it above.

> Sounds we need an extra check in the sources.
> 
> If you don't have time, I can also have a look on this.

Give the procedure above a try first.

>> Release schedule:
>>   If you're happy with this, and confident that you can continue
>> maintaining it from here out (don't worry; I'm not going to get hit by a
>> bus -- but you'll be running point for tftp/tftpd) -- then we can plan
>> the transition and rollout the new packages.
>>
>> We'll have to coordinate
>>   a) uploading the tftp and the updated inetutils packages, and
>>   b) sending the announcements of those two packages
>> I'll need some time for (a) because I have to update inetutil's
>> iu-config and syslog-config scripts; fortunately the major surgery --
>> removing tftp/tftpd -- from inetutils is already done.
> 
> Sure, sounds pretty ok for me. As said, I can confirm that I'll be
> maintaining the tftp package, but most likely, my response times will
> continue to vary as in the last days - depending on my current workload.
> But as I expect a rather limited amount of users needing tftp on Cygwin,
> this should be ok... :-)

Yep, that's my thinking too.

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]