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 10:17 AM, Gernot Hillier wrote:
> I just wanted to escape the circular paradoxon: we can now change the
> string to 5.0-2, but because of that change we'd have to bump up the
> version to -3. But then, the string is wrong again, so we have to start
> another cycle. And this loops indefinitely, see? ;-)

I'm going to nod my head in agreement...it's important that the docu of
a particular release actually agree with the version numbering OF that
release.  It the current 5.0-2 doesn't, that's a mistake.

However, it appears that a 5.0-3 needs to be released anyway, with the
patch for fd6 handling, so...

>> Hmm.  I wonder if cygrunsrv ought to have a --modify function, to go
>> along with --install and --remove.
> 
> That would be indeed helpful if someone(tm) could implement this. :-)

I'll put it on the TODO list...

>> But...I don't think that really
>> needs to be documented as such.
> 
> No, it's [the README, related to standalone installs] pretty ok as it is.

Ack.

>> 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...)
> 
> No, that's a default WinXP64 installation. And I doubt we could do this
> in our product.

Understood.

>> 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.
> 
> Yes, that helped. Now your tftpd starts and seems to work according to a
> quick test.
> 
>> To remove IPv6, do the same thing only click 'Uninstall' instead.
> 
> Yes, this brings back the error as expected.

That's good news...at least things kinda make sense.

>> (*) 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) {
> 
> And that already fixed the issue! Seems it's now working stable w/o IPv6.

Wonderful.  See my reply to your other email.

> It surely still spits on startup:
> 
> tftpd: PID xxxx: cannot open IPv6 socket, disable IPv6: Address family
> not supported by protocol
> 
> But I think this makes sense and we should leave it there.

Right.  This only happens (I think) in standalone mode, and end users
can always use the --ipv4 option to explicitly disable ipv6 support.

> Hmmm, looks like a clear upstream bug which is likely not triggered on
> normal Linux as they always have IPv6 available. 

I think so too.

> Do you like to upstream
> those patches or shall I do that later on?

Well, *most* of the cygwin patches for networking daemons (inetutils et
al) are very very platform specific, so I don't really tend to send them
upstream unless they can be presented in a "clean" way (e.g. don't break
other platforms, for intance).  For example, I wouldn't think of sending
either of these upstream:

01-rename-server.patch ("they" like their current naming convention)
02-missing-header.patch (zomg!!1!! its soooo ugly!!)

but these two probably make sense to (eventually) send up:

03-silence-warnings.patch
04-cygwin-select-on-nonblocking-works.patch


The little fd6 patch, tho, seems like a universal bug and the fix is
rather obvious -- so it should probably go upstream.  Since you're going
to be the maintainer, I think I'll let you do the honors.

--
Chuck



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