From nobody Fri May 28 22:12:40 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C3EDFDBB388 for ; Fri, 28 May 2021 22:12:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FsJpK4vy2z4pZ4 for ; Fri, 28 May 2021 22:12:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82c.google.com with SMTP id h21so3819175qtu.5 for ; Fri, 28 May 2021 15:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3zpeH0E86wMA0iMUXagyGpOMK9uNA1A84C1sdcFs+Ko=; b=ZawUW83VwhJEZHSNvOSfaLdnXJ4tbRTIyePYgmaZiRz/V+TuudpydPLcuVS+xJwew5 dXBJjw0a4ESV5y0ArB3eWS0ECuyzy0HIsr3TYS3KEpDoYw0aKfSo6f5+kb8mGQWDWF0v 57Nb82dFA0ufjQxHYs0PJskGTbHm0gOqAC63e3vH0LCsVerJe4D4BEayRb6cbu9E/E6G wG7hTF9udyxCAOE4yTF0ST9F1cPyoWIvPJ7lEJKLLkUJtzM+I2d0Z8zDQTIM4gAX+dP5 q1myRhnLU+xjcdHX5NTRMpDX0+2/F/hZidZRqwub9V8vLdp00m/2i6FE+l5lfSCdIKeC DnYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=3zpeH0E86wMA0iMUXagyGpOMK9uNA1A84C1sdcFs+Ko=; b=j2hZ5Z7ZKsptRCvWSVXI41ok4n0VhlUOy8MwP5CX8UKg8I8vd1wuwYF5CguUSgJx7o 34jDZYvHYScv/B+nTI/R5z9IJLzScAVUOR/1EAfb7DC0zRnw2453J92DR2xwNa/hStQc /O2CrzfbGUatiVSBmHRDsFDIIM+CfuswWefwjA06qk6Eu8Gi1VkXs+I57YaGFngwLcuq yzKCXP7QElRDA1p3e/X2FxSDLxAPVDl0xHVFwgtf57K5IgdsHtxYKQq7LQu/61ES/JvM uEK2ceuPw+iwgdCo5z4sCc2vLrolfRThpnaC/bHvcKUHT1++lGi77939+pXvFC6fJVEW nwCA== X-Gm-Message-State: AOAM532wWs7/HiNaMUJhI8MuKaIIqa5oXkQrpEn8G4qPFz+LH6TgdqAV T2RmGKpph/qHzqcm3yg/0gCg+MpVR4A= X-Google-Smtp-Source: ABdhPJy6QRfocWZYWQLdOn8yq2Gat1KiXhz1jp+dfIpD7K6tVzYO18k74BdJvgUCWpiOU8M0e9tPwQ== X-Received: by 2002:a05:622a:289:: with SMTP id z9mr5514875qtw.325.1622239960620; Fri, 28 May 2021 15:12:40 -0700 (PDT) Received: from nuc ([142.126.172.178]) by smtp.gmail.com with ESMTPSA id r23sm4170183qtc.32.2021.05.28.15.12.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 15:12:40 -0700 (PDT) Date: Fri, 28 May 2021 18:12:40 -0400 From: Mark Johnston To: Bakul Shah Cc: freebsd-net@freebsd.org Subject: Re: bind(2) fails on 13.0-STABLE when sin_family is 0 Message-ID: References: List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4FsJpK4vy2z4pZ4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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.