On Fri, 2010-10-22 at 12:36 +0200, Guillem Jover wrote:
> Hi!
> 
> On Sat, 2010-10-09 at 00:50:11 +0200, Giovanni Mascellani wrote:
> > Il 08/10/2010 03:19, Doug Brewer ha scritto:
> > > I fired up two consoles, running atftp --option multicast --get -r
> > > ex.bin 10.0.0.1
> > 
> > I think I were wrong, the problem seems to be quite different: the
> > failing sendto() sets errno to 22, which means "Invalid argument". I
> > don't know where is the problem, but have not enough time to investigate
> > right now.
> 
> W/o having checked the actual code I'd say this is due to BSD kernels
> requiring the socklen_t argument of some of the socket functions to be
> exactly the size of the sockaddr matching the address family, and not
> just bigger as in the size of sockaddr_storage. The correct size should
> always be known from addrinfo for example.
> 
> And I'd just assume this is a regression introduced by the patch for
> <http://bugs.debian.org/580473>, Ben Hutchings CCed. Which just seems
> to use sizeof() on struct sockaddr_storage.
> 
> Also skimming over that patch it seems some of the new functions like
> sockaddr_print_addr could be replaced by address neutral counterparts
> like getnameinfo. And the sockaddr_set_port and sockaddr_get_port could
> be avoided by using getaddrinfo and getnameinfo instead, but I've not
> checked deeply.

Please read the code properly instead of idly speculating.  I know all
about getaddrinfo() and it simply doesn't cover everything atftpd needs
to do.

I think the real problem is, as Doug Brewer said, the use of
connect(..., &{AF_UNSPEC}, ...) to disconnect a datagram socket.  I
believe that is a Linux-specific feature and that there is no equivalent
under FreeBSD.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to