As a proof of concept, I made if_input2(), which does if_input() except bpf_mtap_ether(), and made bridge_ifinput() call if_input2(). This way incoming broadcast frames are tapped only once at if_input(). I see pppoe(4) works again with this change. But ether_input() still receives 2 copies.
I'm wondering if bridge_ifinput() just before bridgeintr_frame() in bridge_process() is superfluous. On Mon, Jun 06, 2016 at 01:04:06PM +0900, Masao Uebayashi wrote: > Broadcast frame, coming into a bridge'ed interface, passes if_input() 3 times, > and actually input (ether_input()) twice. > > - A frame enters an interface (e.g. pair(4)), the interface calls if_input() > on it. The frame is queued in if_input_queue. > > - A task running if_input_process() is triggered. It takes the frame and > calls bridge_input(). Frame is queued in bridgeintrq. > > - bridge_process() dispatches frame as multicast/broadcast (if > (ETHER_IS_MULTICAST())) and calls bridge_ifinput() on it, then passes the > frame to bridgeintr_frame(). > > - bridgeintr_frame() calls bridge_broadcast() on it. > > - bridge_broadcast() calls bridge_localbroadcast(), which again calls > bridge_ifinput(). > > bridge_ifinput() is called twice for each broadcast frames. bridge_ifinput() > calls if_input(). Thus 3 if_input() for each. > > These duplicate frames confuse pppoe(4), that's why it stops working. > > On Fri, Jun 03, 2016 at 08:29:50PM +0900, Masao Uebayashi wrote: > > Moving bpf_mtap_ether() from if_input() to (the top of) ether_input() makes > > PPPoE session successfully get established. > > > > On Thu, Jun 02, 2016 at 02:25:39PM +0900, Masao Uebayashi wrote: > > > I spoke too early; I thought frames were broken but actually it was not. > > > What was happening, according to tcpdump(8), was that frames, both > > > broadcast > > > and unicast, are flooded for some reason, and pppoe(4) fails to receive > > > necessary frames in order. > > > > > > OTOH, assigning IP addresses and pinging between pair(4)'s doesn't flood > > > frames. > > > > > > bridge(4) and bpf(4) interacting badly? > > > > > > On Thu, Jun 02, 2016 at 10:34:10AM +0900, Masao Uebayashi wrote: > > > > I'm playing with PPPoE and it (npppd(8) + ppppoe(4)) works fine with > > > > patched > > > > pair(4) interfaces, that's good. > > > > > > > > patch > > > > pair0 --- pair1 > > > > pppoe npppd > > > > > > > > To try more wierd things, I added one pair(4), to which npppd(8) was > > > > listening > > > > on, to a bridge(4). This stops pppoe(4) from working. Seems PPPoE > > > > Discovery > > > > frames sent to pppoe(4) get broken. > > > > > > > > patch bridge0 > > > > pair0 --- pair1 ===== > > > > pppoe npppd > > > > > > > > If I add another interface, e.g. vether(4), to the bridge and let > > > > npppd(8) > > > > listen on vether(4), things work. > > > > > > > > patch bridge0 > > > > pair0 --- pair1 ===== vether0 > > > > pppoe npppd > > > > > > > > I thought adding an interface (pair1) to a bridge does not change what > > > > pair1 > > > > sees logically, or am I wrong? > > > > > > > > Masao
