Hi Giovanni, I confirmed your patch fixes the problem, thanks. There's another problem in multicast support with over one client:
Here's the atftpd log: Oct 07 16:26:19 atftpd[1624.675299648]: Advanced Trivial FTP server started (0.7) Oct 07 16:26:19 atftpd[1625.675299648]: running in daemon mode on port 69 Oct 07 16:26:19 atftpd[1625.675299648]: logging level: 7 Oct 07 16:26:19 atftpd[1625.675299648]: trace enabled Oct 07 16:26:19 atftpd[1625.675299648]: directory: /tftpboot/ Oct 07 16:26:19 atftpd[1625.675299648]: user: nobody.nogroup Oct 07 16:26:19 atftpd[1625.675299648]: log file: /var/log/atftpd.log Oct 07 16:26:19 atftpd[1625.675299648]: not forcing to listen on local interfaces. Oct 07 16:26:19 atftpd[1625.675299648]: server timeout: Not used Oct 07 16:26:19 atftpd[1625.675299648]: tftp retry timeout: 5 Oct 07 16:26:19 atftpd[1625.675299648]: maximum number of thread: 100 Oct 07 16:26:19 atftpd[1625.675299648]: option timeout: enabled Oct 07 16:26:19 atftpd[1625.675299648]: option tzise: enabled Oct 07 16:26:19 atftpd[1625.675299648]: option blksize: enabled Oct 07 16:26:19 atftpd[1625.675299648]: option multicast: enabled Oct 07 16:26:19 atftpd[1625.675299648]: address range: 239.255.0.0-255 Oct 07 16:26:19 atftpd[1625.675299648]: port range: 1758 Oct 07 16:26:35 atftpd[1625.675299968]: socket may listen on any address, including broadcast Oct 07 16:26:35 atftpd[1625.675299968]: Creating new socket: 10.0.0.1:47745 Oct 07 16:26:35 atftpd[1625.675299968]: Serving ex.bin to 10.17.34.51:2132 Oct 07 16:26:35 atftpd[1625.675299968]: received RRQ <filename: ex.bin, mode: octet, blksize: 1468, multicast: > Oct 07 16:26:35 atftpd[1625.675299968]: blksize option -> 1468 Oct 07 16:26:35 atftpd[1625.675299968]: Searching a server thread to give up this client Oct 07 16:26:35 atftpd[1625.675299968]: mcast_addr: 239.255.0.0, mcast_port: 1758 Oct 07 16:26:35 atftpd[1625.675299968]: multicast option -> 239.255.0.0,1758,1 Oct 07 16:26:35 atftpd[1625.675299968]: sent OACK <blksize: 1468, multicast: 239.255.0.0,1758,1> Oct 07 16:26:35 atftpd[1625.675299968]: received ACK <block: 0> Oct 07 16:26:35 atftpd[1625.675299968]: sent DATA <block: 1, size 1468> Oct 07 16:26:36 atftpd[1625.675299968]: received ACK <block: 1> Oct 07 16:26:36 atftpd[1625.675299968]: sent DATA <block: 2, size 1468> Oct 07 16:26:36 atftpd[1625.675300288]: socket may listen on any address, including broadcast Oct 07 16:26:36 atftpd[1625.675300288]: Creating new socket: 10.0.0.1:65499 Oct 07 16:26:36 atftpd[1625.675300288]: Serving ex.bin to 10.66.148.68:2076 Oct 07 16:26:36 atftpd[1625.675300288]: received RRQ <filename: ex.bin, mode: octet, blksize: 1468, multicast: > Oct 07 16:26:36 atftpd[1625.675300288]: blksize option -> 1468 Oct 07 16:26:36 atftpd[1625.675300288]: Searching a server thread to give up this client Oct 07 16:26:36 atftpd[1625.675300288]: Added client 0x28409080 to thread 0x28486040 Oct 07 16:26:36 atftpd[1625.675300288]: multicast option -> 239.255.0.0,1758,0 Oct 07 16:26:36 atftpd[1625.675300288]: sent OACK <blksize: 1468, multicast: 239.255.0.0,1758,0> Oct 07 16:26:36 atftpd[1625.675300288]: Client transfered to 0x28486040 Oct 07 16:26:36 atftpd[1625.675300288]: Server thread exiting Oct 07 16:26:37 atftpd[1625.675299968]: received ACK <block: 2> Oct 07 16:26:37 atftpd[1625.675299968]: sent DATA <block: 3, size 1468> Oct 07 16:26:38 atftpd[1625.675299968]: received ACK <block: 3> Oct 07 16:26:38 atftpd[1625.675299968]: sent DATA <block: 4, size 1468> Oct 07 16:26:39 atftpd[1625.675299968]: received ACK <block: 4> Oct 07 16:26:39 atftpd[1625.675299968]: sent DATA <block: 5, size 1468> Oct 07 16:26:40 atftpd[1625.675299968]: received ACK <block: 5> Oct 07 16:26:40 atftpd[1625.675299968]: sent DATA <block: 6, size 1468> Oct 07 16:26:41 atftpd[1625.675299968]: received ACK <block: 6> Oct 07 16:26:41 atftpd[1625.675299968]: sent DATA <block: 7, size 1468> Oct 07 16:26:41 atftpd[1625.675300608]: socket may listen on any address, including broadcast Oct 07 16:26:41 atftpd[1625.675300608]: Creating new socket: 0.0.0.0:46559 Oct 07 16:26:41 atftpd[1625.675300608]: Invalid request <1> from 0.0.0.0 Oct 07 16:26:41 atftpd[1625.675300608]: sent ERROR <code: 4, msg: Illegal TFTP operation> Oct 07 16:26:41 atftpd[1625.675300608]: Server thread exiting Oct 07 16:26:42 atftpd[1625.675299968]: received ACK <block: 7> Oct 07 16:26:42 atftpd[1625.675299968]: sent DATA <block: 8, size 1468> Oct 07 16:26:43 atftpd[1625.675299968]: received ACK <block: 8> As you can see, I guess there's a problem in Creating new socket: 0.0.0.0:46559. I take a look at the code in tftpd_file.c: /* the socket must be unconnected for multicast */ sa->sin_family = AF_UNSPEC; connect(sockfd, (struct sockaddr *)sa, sizeof(*sa)); FreeBSD doesn't use AF_UNSPEC to disconnect the udp socket. I guess we should rewrite that code, but I have no idea how to do. Maybe you have a patch. I'll test it, thanks. Regards. Doug. 04/10/2010 11:34, Giovanni Mascellani ha scritto: > The problem seems to stay in tftp_io.c, function tftp_send_data: the > sendto call fails with errno = 56 (EISCONN). Don't know why under > kFreeBSD the socket appears to be already connected, I'll investigate > more in the next days. FreeBSD doesn't like that an address is specified to sendto() data on a connected socket, while Linux allows it. Thus, we have to disable the call to connect() on FreeBSD. I'm attaching a patch for it, I intend to NMU it on DELAYED/03. Thanks, Gio. -- Giovanni Mascellani <mascell...@poisson.phc.unipi.it> Pisa, Italy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
