Date: Sat, 20 Aug 2016 21:34:06 +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: <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> In-Reply-To: <eb4c228e-8efe-b519-e85b-87800b3ec7a1@fastmail.net> 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> <eb4c228e-8efe-b519-e85b-87800b3ec7a1@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0f42c5fb-f930-c6e3-75d6-df97f67c201d>