DHCP over vr(4) on bridge(4) through vether(4) no working?

[Raimo Niskanen]

Hello misc@

I have a home router where it seems that DHCP over vr(4) on bridge(4)
through vether(4) does not work.

Sorry about the lack of hard details, it was late last night, I was
tired and need to figure out what details to look into now...

The home router is an ALIX 2d13 which has 3 vr(4) interfaces on board and
one athn(4) on mini-PCI. WAN is vr2, LAN is vr1 and WLAN is athn0.

I had a setup working with dhcpd serving constant addresses based on MAC
address to the LAN on vr0 and athn0 with one address range for vr0 and one
for athn0.

Now I need to start using the 5 GHz Wifi band so I asked the athn0 with
"ifconfig athn0 chan" which channels it supported, tried to configure a 5
GHz one and got an IOCTL error so I guiss it was not acually supported.

Then I bought an ASUS EA-N66 access point that can do 5 GHz and connected
it to vr1.

I did a bridge configuration according to the FAQ with bridge0 containing
athn0, vr1 and vether0. vether0 got the IP address configuration that
athn0 had before, dhcpd was reconfigured to serve vr0 and vether0 and that
worked just fine. DHCP over athn0 passes through bridge0 and vether0 to
dhcpd as well as directly from vr0 to dhcpd.

But DHCP over vr1 through bridge0 and vether0 does not work. I had to
configure a static address on the access point to get any further.

I know that DHCP over vr0 that dhcpd serves directly works, and I know that
it works when dhcpd serves athn0 directly, plus it works when dhcpd serves
athn0 throught bridge0 and vether0.

I tcpdumped vr1 (but now I was getting really tired) and saw 0.0.0.0.bootp
-> 255.255.255.255.bootc packets that I think are DHCP broadcasts from a
client. But when tcpdumping on vether0 I think I did not see them (lots of
chatter), but possibly other strange packets. When letting a client
connect over athn0, on the other hand, I think I saw these broadcast
packets on vether0, and got log entries in /var/log/daemon about dhcpd
giving out a license. Not so when letting a client connect over the access
point and vr0.

So my theory is that either have I missed some stupid little flag, or there
is a bug in vr(4) when it passes packets over a bridge(4) to a vether(4) so
encapsulation is misinterpreted and the IP broadcasts does not arrive in
recognizable shape...

Any hints on how to procede?

[LÉVAI Dániel]

Post by Raimo Niskanen
I have a home router where it seems that DHCP over vr(4) on bridge(4)
through vether(4) does not work.

[...]

Post by Raimo Niskanen
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


Daniel

[Raimo Niskanen]

Post by LÉVAI Dániel

Post by Raimo Niskanen
I have a home router where it seems that DHCP over vr(4) on bridge(4)
through vether(4) does not work.

[...]

Post by Raimo Niskanen
Any hints on how to procede?

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.

Post by LÉVAI Dániel
Daniel

[Raimo Niskanen]

Post by Raimo Niskanen

Post by LÉVAI Dániel

Post by Raimo Niskanen
I have a home router where it seems that DHCP over vr(4) on bridge(4)
through vether(4) does not work.

[...]

Post by Raimo Niskanen
Any hints on how to procede?

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.

[Eric Huiban]

Post by Raimo Niskanen
I did a bridge configuration according to the FAQ with bridge0 containing
athn0, vr1 and vether0. vether0 got the IP address configuration that
athn0 had before, dhcpd was reconfigured to serve vr0 and vether0 and that
worked just fine. DHCP over athn0 passes through bridge0 and vether0 to
dhcpd as well as directly from vr0 to dhcpd.
But DHCP over vr1 through bridge0 and vether0 does not work. I had to
configure a static address on the access point to get any further.
I know that DHCP over vr0 that dhcpd serves directly works, and I know that
it works when dhcpd serves athn0 directly, plus it works when dhcpd serves
athn0 throught bridge0 and vether0.

did you try to add something like this in your pf.conf for "debug" :

set skip on { lo0, vr1, athn0 }

Eric

[Raimo Niskanen]

Post by Eric Huiban

Post by Raimo Niskanen
I did a bridge configuration according to the FAQ with bridge0 containing
athn0, vr1 and vether0. vether0 got the IP address configuration that
athn0 had before, dhcpd was reconfigured to serve vr0 and vether0 and that
worked just fine. DHCP over athn0 passes through bridge0 and vether0 to
dhcpd as well as directly from vr0 to dhcpd.
But DHCP over vr1 through bridge0 and vether0 does not work. I had to
configure a static address on the access point to get any further.
I know that DHCP over vr0 that dhcpd serves directly works, and I know that
it works when dhcpd serves athn0 directly, plus it works when dhcpd serves
athn0 throught bridge0 and vether0.

set skip on { lo0, vr1, athn0 }

Thanks for the tip but I think I have figured this out anyway, and other
packets than DHCP packets pass the firewall. Plus vr1 and athn0 are
configured identically (they are both in group 'lan' and neither of them is
mentioned by name; only the group name is used in pf.conf, so there should
not be any difference between them) and DHCP througn athn0 works.

But I will keep the tip in mind for future use.