From owner-svn-src-head@freebsd.org Sat Aug 20 15:01:51 2016 Return-Path: Delivered-To: svn-src-head@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 272F3BC005D; Sat, 20 Aug 2016 15:01:51 +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 E9E221DD0; Sat, 20 Aug 2016 15:01:50 +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 6914A201A8; Sat, 20 Aug 2016 11:01:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 11:01:49 -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=Pj5M0mpxOizfmg7RoJRrR2rGghw=; b=Q6CEd3 6mSvdjhgwE1UXy++g9PnzNiMpaEGO7HkOjcv8kyA8eu26/dHf6Y7t9VhlhBeIm9K PoSGU+rQF8D1Gw/uIyzeToeMbB6z/6HKNzk7r8rSrju2SfrxblxzqrmB87WamAXU azsT2k1yy/NJcQ4+Q+KsiRnIec7aXhIlBCJIc= 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=Pj5M0mpxOizfmg7 RoJRrR2rGghw=; b=EPF66NF5cq0EPSgLVcBl76ujSPVAyg9jLi62fitbW8pdCBF 0HtSZ7QLocjXWrEDev4G+mmuGBD6PRk3OAW7kXUX3OUcgp12jVLG1WFUZ2os/42J nLA1XKFqm8N2oD+TOLxWkZmL85p9+hkB1r0lH3Rv2/nmwl566+C99ogpDEx4= X-Sasl-enc: aUdf3kewzlhPGIt7OEyQ64m95xBUAmC3hV4wOBoLrkOr 1471705308 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 4F568CCE6C; Sat, 20 Aug 2016 11:01:48 -0400 (EDT) Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Ryan Stone References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> Cc: Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Bruce Simpson Message-ID: Date: Sat, 20 Aug 2016 16:01:40 +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-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 15:01:51 -0000 On 20/08/16 15:52, Ryan Stone wrote: > It is perfectly legal for broadcast packets to be addressed to the > end of a P2P or non-Ethernet link, which may not set M_BCAST or > M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access > (NBMA)) but the situation may be readily observed with loopback or > tunnels. > > Can you give an example of a tunneling protocol support by FreeBSD that > may be affected? I looked and didn't see any. OpenVPN, as best that I > can tell, injects frames into a tap interface, which appears as a > Ethernet interface, for example. Potentially any and all PPP, tun(4); any link layer with plain IP on top of it other than Ethernet, which may not set M_BCAST for an IPv4 broadcast packet (or does not distinguish between broadcast and unicast/multicast packets). if_ethersubr.c does set M_BCAST correctly for Ethernet broadcast packets in the receive path. That is guaranteed, and the majority of Ethernet network drivers will pass packets up the stack through it more or less directly. tap(4) is an exception because, as you rightly point out, it is pretty faithfully Ethernet, although I may have had to add code around Ethernet address conditions like this to it in the very distant past. tun(4) on the other hand is a plain, PPP-like, IP tunnel. But this mbuf flag is not guaranteed to be set in all situations; e.g. where the link layer does not have the concept of broadcast being distinct from other kinds of network traffic. PPP and ATM are the most obvious examples.