This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
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