Re: bind(2) fails on 13.0-STABLE when sin_family is 0

On Fri, May 28, 2021 at 03:21:15PM -0700, Bakul Shah wrote:
> On May 28, 2021, at 3:12 PM, Mark Johnston <markj@freebsd.org> wrote:
> > 
> > On Fri, May 28, 2021 at 02:40:26PM -0700, Bakul Shah wrote:
> >> ttcp runs fine on 13.0-RELEASE but fails on -stable.
> >> 
> >> The culprit seems to be bind(2). Running ttcp under gdb:
> >> 
> >> $ gdb a.out
> >> Reading symbols from a.out...
> >> (gdb) b 295
> >> Breakpoint 1 at 0x203127: file ttcp.c, line 295.
> >> (gdb) run -s -r
> >> Starting program: /usr/ports/benchmarks/ttcp/work/ttcp-1.12_2/a.out -s -r
> >> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
> >> ttcp-r: socket
> >> 
> >> Breakpoint 1, main (argc=3, argv=0x7fffffffd9b0) at ttcp.c:295
> >> 295             if (bind(fd, (struct sockaddr *) &sinme, sizeof(sinme)) < 0)
> >> (gdb) p/x sinme
> >> $1 = {sin_len = 0x0, sin_family = 0x0, sin_port = 0x8913, sin_addr = {
> >>   s_addr = 0x0}, sin_zero = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
> >> (gdb) n
> >> 296                     err("bind");
> >> (gdb) p errno
> >> $2 = 47
> >> 
> >> 
> >> $ errno 47
> >> #define EAFNOSUPPORT    47              /* Address family not supported by protocol family */
> >> 
> >> Did something change post 13.0-RELEASE that requires specifying sin_family?
> >> Thanks!
> > 
> > Yes, some changes were made recently to make sockaddr validation
> > stricter.  Several other operating systems also have this requirement.
> > Linux seems to be a bit more relaxed in that AF_UNSPEC (0) is permitted
> > if and only if the bind address is INADDR_ANY, which is the case here.
> > 
> > Since 2001 the benchmarks/ttcp port has carried a patch to specify
> > sin_family.  Is there some reason it cannot be used here?  I don't
> > object to re-allowing ttcp's unpatched behaviour if necessary.
> 
> The patch was only for the transmit case. Making it unconditional fixed it.
> I asked mainly because I was surprised and wanted to make sure this was an
> intended change.
> 
> Thanks for your response!

I see, thanks.  In that case it is probably best to restore some level
of compatibility: https://reviews.freebsd.org/D30539