From owner-svn-src-all@freebsd.org Sat Aug 20 20:34:17 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99E9CBC0C81; Sat, 20 Aug 2016 20:34:17 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67D101799; Sat, 20 Aug 2016 20:34:17 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1242E20255; Sat, 20 Aug 2016 16:34:16 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 16:34:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=M7X4CaGypMylhBzxghJSCv+oHWo=; b=EOJJYG xbUmLKZuneEjiCIUSktkelx+QjFvtC3QpFzWFURxxSR3QHj0MGae5hXRp5qAdBaT g+qFLEIYW/gCCMHAZlH4CNQExwM0Xo/HNqdrHYYbtZb0zhfjNe2R0Oh81MEUgViI LDInhTsFEJyA+QeakHthmJQngygUYBT5sPeV4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=M7X4CaGypMylhBz xghJSCv+oHWo=; b=KUGqd+8g0hrUhwZaAsE+oRgPSwxBX38vlw1CGY11W+zRP4A lkPQmfQlk1xa7ptXALhzdQgQP1GdRhNXur12Kf5ZBj3INUuvwWGEDuYYNIUIlNz9 9Wc212G84910cblVxXs2030gew6QAKMdN/Pf10Za04DaIeHXFOeCxLIwVEQg= X-Sasl-enc: 1gldOMlIDvVgByxfQ2KhLaQPibzj7HX+xqcoHNgmK9Io 1471725255 Received: from pion.local (cpc96954-walt26-2-0-cust843.13-2.cable.virginm.net [82.31.91.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 07B94F2983; Sat, 20 Aug 2016 16:34:14 -0400 (EDT) Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Ryan Stone , Slawa Olhovchenkov References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <20160820173050.GQ22212@zxy.spb.ru> <20160820184506.GV8192@zxy.spb.ru> Cc: "svn-src-head@freebsd.org" , Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , Adrian Chadd From: Bruce Simpson Message-ID: <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> Date: Sat, 20 Aug 2016 21:34:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 20:34:17 -0000 On 20/08/16 21:05, Bruce Simpson wrote: > Unless I am missing something crucial here? As far as I can tell, > arpresolve() unconditionally resolves L2 next-hop to the value of > ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by > default for Ethernet ifnets: FF:FF:FF:FF:FF:FF. > > Would that not get past the M_BCAST check which replaced the call to > in_broadcast()? Based on my reading of the UDP-and-plumbing layer, it looks like we will only see FF:FF:FF:FF:FF:FF being used by the undirected IPv4 broadcast address, 255.255.255.255. But, in fact, this is probably a far more valid address to use for discovery services than the x.x.x.255-style IPv4 directed broadcast address, as, for Ethernet at least, it is guaranteed not to propagate beyond 1 union-of (on-link broadcast domain (layer 2, hop 1) & other ways that IPv4 subnet is bridged). So, Ryan -- your original reading of how in_broadcast() behaves is correct, modulo the all-ones bypassing it. (I believe dhclient and isc-dhcpd bypass it at BPF injection, though.)