On Fri, Oct 07, 2016 at 11:07:43AM +0200, Raimo Niskanen wrote:
> On Fri, Oct 07, 2016 at 10:42:40AM +0200, LÉVAI Dániel wrote:
> > Raimo Niskanen @ 2016-10-07T09:46:06 +0200:
> > > Hello misc@
> > >
> > > I have a home router where it seems that DHCP over vr(4) on bridge(4)
> > > through vether(4) does not work.
> > >
> > [...]
> > > Any hints on how to procede?
> >
> > Just a shot in the dark, but maybe:
> >
> > http://marc.info/?l=openbsd-misc&m=147462832805431&w=2
> > http://undeadly.org/cgi?action=article&sid=20160725144108
>
> Nice shot, but a close miss. I have vr0-bridge0-vether0 and no dhclient
> running on neither vr0 nor vether0. The client runs on vr2. Also I see
> no log entrys in /var/log/daemon from dhcpd about getting a DHCPDISCOVER
> and sending a DHCPOFFER, which I get when the request comes in over
> athn0-bridge0-vether0... So it is the incoming that does not arrive.
I have to back from that statement. Now I am convinced it is the same bug!
And it seems to be enough to have a dhclient running on the same machine as
the bridge, or on the same interface type.
I have dhclient running on vr2 and bridge0 contains vr1, athn0 and vether0.
Some more tcpdumping shows that the DHCPDISCOVER comes in on vr1 and is not
distributed to any other bridge member. But when a DHCPDISCOVER comes in on
athn0 it is distributed to vr1 and vether0. dhcpd listens on vether0 but
the reply to DHCPDISCOVER is not delivered through vether0 and the bridge.
It shows up on athn0 directly and is not distributed to the other bridge
members.
So dhcpd and the bridge does some monkey business, possibly assisted by
dhclient working on an interface not in the bridge.
I think these all concern the same problem:
http://marc.info/?l=openbsd-misc&m=147462934705670&w=2
http://marc.info/?l=openbsd-bugs&m=147291369828477&w=2
http://marc.info/?l=openbsd-tech&m=147333147600814&w=2
so the devs are probably working on a solution.
My current workaround is to have dhcpd listen to vr0, vr1 and athn0, and
give out different address ranges on the different interfaces.
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
