Date: Sat, 20 Aug 2016 23:41:06 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Bruce Simpson <bms@fastmail.net> Cc: Ryan Stone <rysto32@gmail.com>, "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: <20160820204106.GW8192@zxy.spb.ru> In-Reply-To: <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> References: <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> <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > 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.) What purpose to analyse L2 header? Yes, curently FreeBSD don't support multiaccess media other then ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be absent.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160820204106.GW8192>