On Thu, Aug 19, 2021 at 06:42:25PM +0100, Étienne wrote:
> On 31/07/2021 19:27, Stefan Sperling wrote:
> > On Sat, Jul 31, 2021 at 07:02:35PM +0100, Étienne wrote:
> > > On 30/07/2021 04:37, Theo de Raadt wrote:
> > > > dhcpleased (and a few other daemons) use bpf, thus see raw packets
> > > > from the wire before pf can block them. Most daemons of this type
> > > > also use bpf to send packets, and pf doesn't see these either
> > > Does that prevent dhcpd from listening on any virtual interface? I'm
> > > trying
> > > to have it listen for requests on a vether in a bridge, and that fails (or
> > > I'm making a mistake).
> >
> > It should work, unless are running dhclient/dhcpleased on the same machine,
> > because the bpf filter will eat DHCP-related packets. You'll know whether
> > this affects you by checking whether dhcpd starts working when you kill the
> > DHCP client.
>
> Thanks for your help, Stefan, and sorry for coming back so late on that.
> Despite the tip, I'm afraid it doesn't work.
>
> I have two Ubiquiti EdgerouterLite running 6.9, these boxes have 3
> interfaces cnmac0, cnmac1 and cnmac2. I bridge cnmac0 and cnmac1, and I
> connect cnmac0 on both boxes to one switch, and cnmac1 on both boxes to
> another switch. I turn RSTP on all these interfaces and on the switches, add
> a vether0 with an IP address (in 172.16.0.0/16) in bridge0 on either box,
> and I have connectivity.
>
> I also configure an IP address on cnmac2 (in 192.168.1.0/24). Then I
> configure dhcpd to listen on cnmac2 and on vether0:
>
> dhcpd_flags=-y vether0 -Y vether0 vether0 cnmac2
>
> With this setup, I see DHCP leases added in the 192.168.1.0 range, but none
> in the 172.16.0.0 range. Moreover, I see DHCP requests when running tcpdump
> on bridge0, but not on vether0. So I'm not sure what's preventing it to
> work.
>
> My configuration files content:
>
> % cat /etc/hostname.cnmac0
> up
> % cat /etc/hostname.cnmac1
> up
> % cat /etc/hostname.cnmac2
> inet 192.168.1.4 255.255.255.0 NONE
> !route add 0.0.0.0/0 192.168.1.254
> inet6 autoconf
> up
> % cat /etc/hostname.vether0
> lladdr fe:e1:ba:d0:be:d3
> inet 172.16.0.4 255.255.255.0
> up
> % cat /etc/hostname.bridge0
> add cnmac0
> stp cnmac0
> add cnmac1
> stp cnmac1
> add vether0
> maxaddr 1000
> timeout 40
> up
> % cat /etc/dhcpd.conf
>
> option domain-name-servers 192.168.1.254;
> default-lease-time 14400;
> max-lease-time 86400;
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> option routers 192.168.1.254;
>
> range 192.168.1.16 192.168.1.126;
> }
>
> subnet 172.16.0.0 netmask 255.255.255.0 {
> option routers 172.16.0.1;
>
> range 172.16.0.16 172.16.0.126;
> }
>
> Running tcpdump shows this:
>
> % doas tcpdump -ve -i bridge0 "port 67 or port 68"
> tcpdump: listening on bridge0, link-type EN10MB
> 19:16:57.596572 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1120 [|bootp] (ttl 64, id 0,
> len 328)
> 19:17:00.597025 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1123 [|bootp] (ttl 64, id 0,
> len 328)
> 19:17:03.600246 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1126 [|bootp] (ttl 64, id 0,
> len 328)
> […]
> 19:17:42.630441 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1165 [|bootp] (ttl 64, id 0,
> len 328)
> ^C
> 74 packets received by filter
> 0 packets dropped by kernel
> % doas tcpdump -ve -i vether0 "port 67 or port 68"
> tcpdump: listening on vether0, link-type EN10MB
> ^C
> 1320 packets received by filter
> 0 packets dropped by kernel
>
> Any idea?
I suspect the packets towards vether0 are being dropped by pf.
What does your pf.conf look like?
Do you see anything related in tcpdump -n -i pflog0, provided you've
using 'log' statements on your block rules in pf.conf?
Does adding this as the final rule help?
pass on bridge0 no state
