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
