Date: Sat, 20 Aug 2016 21:05:36 +0100 From: Bruce Simpson <bms@fastmail.net> To: Ryan Stone <rysto32@gmail.com>, Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Ryan Stone <rstone@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <eb4c228e-8efe-b519-e85b-87800b3ec7a1@fastmail.net> In-Reply-To: <CAFMmRNy-e1uzdtz2cb5DAa9kRd%2BkHg%2BmWbf=HNDWVdGGjOPUWA@mail.gmail.com> References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> <CAFMmRNyi=PwE9pc9_8wCU63=HttUzFR4Zh2v=uHKcQ-zaLxdJQ@mail.gmail.com> <fcb33eac-ec99-03c7-57b5-f24f86c4f41a@fastmail.net> <CAFMmRNwDPy4Hd35DrfREZQzjvd89qw=zhEriddG8U8NV7tD=EA@mail.gmail.com> <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <CAFMmRNypgJc00XH277oB3EEGje4xq%2B8_qcJfZu4jjBfTfa7GGQ@mail.gmail.com> <20160820173050.GQ22212@zxy.spb.ru> <CAFMmRNx=2v=M8GCBQ_cN4pnuZ4VnyzncwAgsqMUE=ebz7pkp2A@mail.gmail.com> <20160820184506.GV8192@zxy.spb.ru> <CAFMmRNy-e1uzdtz2cb5DAa9kRd%2BkHg%2BmWbf=HNDWVdGGjOPUWA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20/08/16 19:57, Ryan Stone wrote: > > > On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov <slw@zxy.spb.ru > <mailto:slw@zxy.spb.ru>> 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()?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eb4c228e-8efe-b519-e85b-87800b3ec7a1>