Date: Fri, 28 May 2021 15:21:15 -0700 From: Bakul Shah <bakul@iitbombay.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: bind(2) fails on 13.0-STABLE when sin_family is 0 Message-ID: <9CF9F43D-CEB5-4856-AC1E-455DFE66DC69@iitbombay.org> In-Reply-To: <YLFq2FuJVzcgpMc%2B@nuc> References: <D9E4EE46-E813-44F4-8BC2-971E1439A68D@iitbombay.org> <YLFq2FuJVzcgpMc%2B@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 28, 2021, at 3:12 PM, Mark Johnston <markj@freebsd.org> wrote:
>=20
> On Fri, May 28, 2021 at 02:40:26PM -0700, Bakul Shah wrote:
>> ttcp runs fine on 13.0-RELEASE but fails on -stable.
>>=20
>> The culprit seems to be bind(2). Running ttcp under gdb:
>>=20
>> $ 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=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp
>> ttcp-r: socket
>>=20
>> Breakpoint 1, main (argc=3D3, argv=3D0x7fffffffd9b0) at ttcp.c:295
>> 295 if (bind(fd, (struct sockaddr *) &sinme, =
sizeof(sinme)) < 0)
>> (gdb) p/x sinme
>> $1 =3D {sin_len =3D 0x0, sin_family =3D 0x0, sin_port =3D 0x8913, =
sin_addr =3D {
>> s_addr =3D 0x0}, sin_zero =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, =
0x0}}
>> (gdb) n
>> 296 err("bind");
>> (gdb) p errno
>> $2 =3D 47
>>=20
>>=20
>> $ errno 47
>> #define EAFNOSUPPORT 47 /* Address family not =
supported by protocol family */
>>=20
>> Did something change post 13.0-RELEASE that requires specifying =
sin_family?
>> Thanks!
>=20
> 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.
>=20
> 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!
-- Bakul=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9CF9F43D-CEB5-4856-AC1E-455DFE66DC69>