Thanks for the explanation. I am curious though - is dhclient really the right place to fix this? I might use some other dhcp client (dhcpcd in ports for example) or some other application that uses BPF. Should every userland program using BPF have to worry whether or not it is breaking bridging?
On Sun, Sep 4, 2016 at 9:12 AM, Ted Unangst <t...@tedunangst.com> wrote: > Aaron Riekenberg wrote: > > Based on Martin's hint I tried an experiment - I configured em0 > statically > > instead of using dhcp. This fixes my problem. > > > > So to summarize: in 6.0 running dhclient on a bridge-member interface > > breaks dhcp traffic passing through the bridge. This worked in 5.9. > Also > > the FAQ bridge example uses DHCP on a member interface: > > http://www.openbsd.org/faq/faq6.html#Bridge > > So everybody understands what's happening behind the scenes and why this > is a > new problem... > > Long ago, a flag was added to BPF filters to drop matching packets. > dhclient > sets this flag on the filter it uses to listen to dhcp packets, which has > the > (intended) effect of causing dhclient to eat the packet so nobody else sees > it. > > Between 5.9 and 6.0, some code in the network stack was shuffled about and > this changed the order in which some operations were performed. In > particular, > now BPF sees packets before bridge forwards them, instead of after. > Therefore, > if dhclient eats the packet, it won't be forwarded. > > dhclient was modified to only match packets intended for *this* machine by > specifying a filter for the local machine's MAC address. However, there are > buggy dhcp servers that always send packets to the broadcast address. The > dhclient filter change was reverted and it once again eats all dhcp > packets. > >
