From owner-svn-src-head@freebsd.org Sat Aug 20 20:05:47 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 11D7CBC02C9; Sat, 20 Aug 2016 20:05:47 +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 D41A315B2; Sat, 20 Aug 2016 20:05:46 +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 BC830202B5; Sat, 20 Aug 2016 16:05:45 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 16:05:45 -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=0aA0EwChDLlZjobxX68vrGtvK6c=; b=ipXi6g W9EH8gUVIQhw5/UwOnME5dLFhE38cZAjSks2lqZLRJ8Qf3CccD5cfCpHtJIUSxg3 Fg8BOYbInaT/ob04WM7V3A2D/rjKjDAWgYg2tQ/2E+z/r5Larvow+O1BH0V9p171 w1kEHttXN6/iPWf/A/46ZqRh5Kizj4wOj3Qxo= 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=0aA0EwChDLlZjob xX68vrGtvK6c=; b=W1FbtqDOq9W6un0/6x0JIz0EwMXqSxmIizApWAGXQqIXE8+ OsDABX9aUXzh0Su+QFYJIib9NoQAOxv0THxD6c6BmsoXrLzIP+9jh0h/lBbAnUaj gNES2E7cFRM/73piUT6YgqEjK3H+lTix0+D0oS2pJwNwWE+tUMJCUJvvpzHw= X-Sasl-enc: MF2XJ7uoXbQbK+CQB3Fav63UhRk+v+eFwzUr74cXXwTe 1471723545 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 88C8EF296F; Sat, 20 Aug 2016 16:05:44 -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: Date: Sat, 20 Aug 2016 21:05:36 +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 20:05:47 -0000 On 20/08/16 19:57, Ryan Stone wrote: > > > On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov > wrote: > > You also can recive this on ethernet too, IMHO, in case of /32. > Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be > relaxed on this. > > > There is no broadcast address on a /32 network. Independent of my > change, we would not treat a packet received on a /32 network as a > broadcast here because in_broadcast() will return 0 for it. Hmm. That is not entirely true for /32. Even though the link layer might be Ethernet in that case, in the traditional BSD ifnet sense, while the broadcast address slot may have the same value (and actual location) as the peer end of a P2P (as in generically IFF_PPP, not just pppd(8)) interface), because it's on an Ethernet (IFF_BROADCAST) interface, the host part of the /32's value in in the broadcast address is still valid, and will probably get mapped that way if M_BCAST is set on outgoing traffic. (You are, after all, going to go through ARP on Ethernet, even for a /32, so that mapping will be triggered.) 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()?