From owner-freebsd-net@freebsd.org Sun Mar 17 04:37:23 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50340154BDF6 for ; Sun, 17 Mar 2019 04:37:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF1658C6AD for ; Sun, 17 Mar 2019 04:37:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8600CC74E for ; Sun, 17 Mar 2019 04:37:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f42.google.com with SMTP id y62so1367628lfc.13 for ; Sat, 16 Mar 2019 21:37:22 -0700 (PDT) X-Gm-Message-State: APjAAAVUHoXQshQYYOP0c1Q/e8KHT9hdEfZXH9VNWo+Xpy2DL/eJGJEJ MYzKKTmzeheu09HqTvX0WumCHeszV3Rew3M7cbg= X-Google-Smtp-Source: APXvYqww6Z/d/IydJf2/evYrYkz498mJ2ZAEGvuRvyKiLu2mfYJuGQ3PAFDUrJDp7gRoyyHZve893+UXoma+ATbJUis= X-Received: by 2002:a19:7503:: with SMTP id y3mr6111423lfe.83.1552797440842; Sat, 16 Mar 2019 21:37:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sat, 16 Mar 2019 23:37:09 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: if_bridge(4)/bpf on incoming packets To: freebsd-net Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: DF1658C6AD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 04:37:23 -0000 On Sat, Mar 16, 2019 at 11:17 PM Kyle Evans wrote: > > Hi, > > Given a setup like: > > ifconfig bridge0 create > ifconfig bridge0 addm em0 addm wlan0 up > > Packets coming in on em0 that get routed to wlan0 by the bridge will > not be passed over to wlan0's bpf(4). I have an open review [0] that > proposes changing this so that if we're passing traffic over a bridge, > it gets exposed to the destination interface's bpf interface assuming > it's not the interface that just injected it into the bridge. > > I don't know the history here, though- is there any particular reason > bridge doesn't/shouldn't do this now, or is it just that it's not > useful by conventional (read: almost all) usage of a bridge? > Further reading leads me to believe that it's maybe technically a bug -- see [1], where packets running through bridge_forward and destined for a member interface *do* get pushed through bpf. The problem is that this can never happen, because we've either grabbed it and bailed out in bridge_input [2] before we call bridge_forward, or we're calling bridge_forward for broadcast/multicast [3]. This also leads me to wonder if we should be invoking pfil hooks before bailing out of bridge_input in this case, though, so that pfil hooks have a chance to operate on bridge-passed local traffic as well. [1] https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2222 [2] https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2480 [3] https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2367