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