From owner-freebsd-net@freebsd.org Sun Mar 17 04:17:36 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 ED688154B45D for ; Sun, 17 Mar 2019 04:17:35 +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 1D4E48BC80 for ; Sun, 17 Mar 2019 04:17:35 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 BBCD8C519 for ; Sun, 17 Mar 2019 04:17:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f173.google.com with SMTP id x13so11138021ljj.5 for ; Sat, 16 Mar 2019 21:17:34 -0700 (PDT) X-Gm-Message-State: APjAAAW0yvRnLUNRChvHOHjV998nFRZ6nGg4JIf5tToPGmEIyAbBsVBW F+cbDkrXCMfxgmuWaaScvuU88Rok575P4dQgfdw= X-Google-Smtp-Source: APXvYqwRl6mtCOWkCJAle2d75g84uT4YYx6XWfoMOrzwtj9tfpkAH1RCch0WIc9Kb3VerA0Dr46iHXrKts3Dz8RE8AE= X-Received: by 2002:a2e:88d0:: with SMTP id a16mr6508944ljk.77.1552796253285; Sat, 16 Mar 2019 21:17:33 -0700 (PDT) MIME-Version: 1.0 From: Kyle Evans Date: Sat, 16 Mar 2019 23:17:21 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: if_bridge(4)/bpf on incoming packets To: freebsd-net Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 1D4E48BC80 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] 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:17:36 -0000 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? My motivation is that in a particular testing setup I am playing with, either em0 or bridge0 get a DHCP address and wlan0 (actually not wlan0 in my testing setup, but keeping with the above example for convenience) also needs to pull a DHCP address from the em0 side of the bridge for... reasons. =) I also anticipate needing to actually monitor traffic received from the bridge by wlan0 along with traffic received on wlan0, rather than monitoring the bridge, so the above change makes this most convenient. Thanks, Kyle Evans [0] https://reviews.freebsd.org/D19586