Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
On Sun, Oct 09, 2016 at 02:29:12PM +0200, Eric Huiban wrote:
> Raimo Niskanen wrote:
>
> > 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 }
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.
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
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
Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
Raimo Niskanen wrote:
> 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
Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
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. > > > Daniel -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
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 Daniel
DHCP over vr(4) on bridge(4) through vether(4) no working?
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? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
