From owner-svn-src-head@freebsd.org Sat Aug 20 18:14:41 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 DBAF3BC055B; Sat, 20 Aug 2016 18:14:41 +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 9F7301D21; Sat, 20 Aug 2016 18:14:41 +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 AB6C5202AD; Sat, 20 Aug 2016 14:14:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 14:14:40 -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=e2mvHCawrJuBq0N8ULSLjAcU72w=; b=iA3rvP jF/2Qm19n16LgGF7nu/g8zYi5dxYSqhObPPe61cjQatqchQfLum9bT+4HOzR+w/X +bX8w1VrJBpox+WRBBbcoVjMM2A3y4IrdhBeqfdXWHYiKjvjaVc7QvZdT3Nu14ir i20Ic3SwIaLnVY9J1p6RIIREzrZ38uNaeTofE= 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=e2mvHCawrJuBq0N 8ULSLjAcU72w=; b=uZVUPrmmfIHd0dfmJ1ir9YA4vdvn65oQrWPFdJgpQ7UNPKF 5yTkyeWxnJF+ckjUMDwWW+PMDaUwt9kXXX2q3jKIe6Dkb6QAmlwM8TjK7+Zc7Hsa 4pabbdy44DKajReGMqAT39zuzRatjEb+P7Xabo/xpGGKihHChCqX/HVkutyo= X-Sasl-enc: nwhWTdUlbtl42Nj5JUtjqr2wj6SMLe3vzp0YS5xgeBTf 1471716880 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 9D442F2983; Sat, 20 Aug 2016 14:14:39 -0400 (EDT) Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Adrian Chadd , Ryan Stone 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> Cc: Slawa Olhovchenkov , "svn-src-head@freebsd.org" , Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" From: Bruce Simpson Message-ID: Date: Sat, 20 Aug 2016 19:14:31 +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 18:14:42 -0000 On 20/08/16 19:09, Adrian Chadd wrote: > On 20 August 2016 at 11:02, Ryan Stone wrote: >> On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: >>> For host enought have [hidden] alias with broadcsts bits. >>> Anyway, don't should relay on the L2 information, you can recive L3 >>> unicast addressed packets (with alien dst IP address) in L2 broadcas >>> packet. >> >> This is still handled correctly. The new code only checks for L3 broadcast >> addresses on L2 broadcast packets, but we still check the L3 address before >> treating it as a broadcast. The problem is that I assumed that all paths >> into the IP stack would set M_BCAST, but as Bruce has pointed out there are >> cases like PPP which do not. > > So why not fix those paths? Because it would involve doing something similar to what if_ethersubr.c does right now: a direct comparison with FF:FF:FF:FF:FF:FF. Doing so outside of Ethernet would be invasive and one of those 'bad' layer crossings. This is tricky to get right. NetBSD introduced the M_PROMISC flag to cover situations which can occur when Ethernet can be re-entered by layers 'above' its original invocation. (I merged it here.) Ryan proposes slipping the definition of M_BCAST to include the network layer, inside ip_input() itself. That would not strictly violate layering, but bends the original meaning of the flag somewhat. That may work, provided it doesn't tread on the toes of anything above it. However the situation is somewhat similar to that of M_PROMISC.