This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] tftp-hpa 5.0
Hi there.
On 19.11.2010 13:43, Charles Wilson wrote:
> 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:
[...]
> 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.
My tests were based on 5.0-2.
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? ;-)
>>> 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).
[...]
> 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. :-)
> 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.
No, it's pretty ok as it is.
>> 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...)
No, that's a default WinXP64 installation. And I doubt we could do this
in our product.
> 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.
> (*) 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.
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.
> 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.
Hmmm, looks like a clear upstream bug which is likely not triggered on
normal Linux as they always have IPv6 available. Do you like to upstream
those patches or shall I do that later on?
--
Gernot Hillier
Siemens AG, CT T DE IT 1, GTF System Architecture & Platforms