Date: Sun, 21 Aug 2016 03:04:00 +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: <20160821000400.GY8192@zxy.spb.ru> In-Reply-To: <8ac23bd1-dcb3-7c64-f195-5039f9af0eaf@fastmail.net> References: <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> <20160820204106.GW8192@zxy.spb.ru> <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> <20160820220510.GX8192@zxy.spb.ru> <8ac23bd1-dcb3-7c64-f195-5039f9af0eaf@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: > On 20/08/16 23:05, Slawa Olhovchenkov wrote: > > I am think this substitution is very bad idea (by design). > > Also, on transmit side this is must be irrelevant on received L2 > > header (and this in many cases this is will be L2 unicast packet). For > > other cases packet will be created on host and don't have any received > > information. > > > > Whilst I agree with your concerns about multipoint, I support the > motivation behind Ryan's original change: optimize the common case. Oh, common case... I am have pmc profiling for TCP output and see on this SVG picture and don't find any simple way. You want to watch too? What benefits from this optimisation? I both cases we need check IP DST for broadcast address. This check my break some network setup (we already have broken tunnel interface in case of overlap remote inner and outer tunnel address). > On the other hand, I'm suggesting a slight extension to it -- one which > would probably require adoption across some L2-exposed subsystems, or > anywhere which might reinterpret an M_BCAST from re-entrant > encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon > then decides it needs to be NATted and forwarded somewhere else). I think this is seperate task and forward or drop must be controlled separatly. In some cases broadcast must be forwarded. > Whilst I believe the scope for problems like this are limited (and > perhaps to Netgraph permutations), I do believe they exist, and should > be defensively coded for. > > And: If, the logic for this can be factored out into one additional bit, > in a conditional branch (or small set of those) in terms of delta to the > existing FreeBSD data plane path -- i.e. my suggestion; > > Then: we should be able to preserve correctness for multipoint > configurations, without sacrificing performance. I am fear about perforance impact, code complexy and network setup break. > Or, a possible tie-breaker: > > ...we ensure that M_BCAST is cleared at all times before possible > re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols > decide themselves if re-entered about M_BCAST based on DMAC. And set only by NIC? By performance view. > > On received side for host relaing on L2 information for accepting > > packet as host targeting sound like security hole. > > > > In router case receiving broadcast packet in any way need additional > > check for dst IP address (host part is all zero or all one? what about > > handling this broadcast type (RFC talk about conroling variation of > > this)? what about sysctl control of receiving routed broadcast > > packets? what about handling 255.255.255.255?) > > I believe most of this is already special-cased in ip_fastfwd.c (which > gnn@ of course has merged, as it's full of sensible FIB-like operators > which most router forwarding planes adopt on *their* IP input paths up > to the forwarding decision), assuming the Ethernet input path colours > packets with the right flags. Yes. And MAC broadcast independed. And can't be depend on this. > Although, no direct distinction between IPv4 directed or undirected > broadcast is made, until that code (or a full rtalloc()) is hit. I am just about RFC1812 4.2.2.11 "a router MAY have a configuration option to prevent reception of these [Directed Broadcast] packets" and absent like options for Limited broadcast packets. > In the past, I have tried to "hack around" the issue on the output > (send) side, by introducing IP_ONESBCAST from BSD/OS. > > The fundamental problem there is that the IPv4 socket APIs were never > designed to deal with 'with link' as well as 'with destination' > particularly well -- i.e. to direct traffic to a particular host, with > correct L2 resolution, but over a specific choice of link (or even, > class of link). For load sharing over multiple NIC in one subnet? > So, for correct behaviour when handling packets like this, the XORP FEA > and libfeaclient frameworks would attempt to fully-bind control sockets > requiring broadcast input where possible (OLSR being one candidate, but > there are also other protocols requiring them). > > > In any way, this is irrelevant to L2 broadcast MAC and present L2 > > broadcast flags. > > On the contrary, I believe in teasing as much explanation about the > Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends > much background to the original problem posed by Ryan's change, to those > who may not be from a primarily networking-oriented background.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160821000400.GY8192>