On Wednesday, 12 April 2017 14:40:28 -04 trondd wrote:
> On Wed, April 12, 2017 4:27 am, Stuart Henderson wrote:
> > On 2017-04-12, Jordon <open...@sirjorj.com> wrote:
> >>> rcctl enable dhcrelay
> >>> rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your
> >>> routers
> >>
> >> address"
> >>
> >>> rcctl start dhcrelay
> >>>
> >>> and possibly add -d (log to stderr) to see what its doing.
> >>
> >> Thank you! That got it working! So why is that necessary? Doesnt the
> >> bridge
> >> just forward everything? Or are DHCP requests broadcasts that dont get
> >> forwarded?
> >
> > It shouldn't be necessary, dhcrelay is normally used when you have a
> > subnet behind a router, and the DHCP server is a separate machine on a
> > different subnet.
> >
> > Could it be a PF rule problem?
> >
> > Normally you would only have an IP address on one member of the bridge,
> > just "up" on the others..
>
> I have this problem as well. DHCP requests go out over the bridge to the
> main interface. The response comes back to the main interface but never
> goes to the bridge.
>
Same here. I read somewhere (need to look it up again) that with 6.1 this DHCP
problem with bridges got solved. I'm on 6.0 right now but will report back as
soon as I upgraded to 6.1.
My bridge is between athn0, re2 and vether0 on an APU1.
My DHCP server is on another machine on the same network.
> I'm trying to use vmm VMs on a bridge. I've tried set skip on {bridge
> tap}, and pass quick on {egress bridge tap} proto {tcp udp} from any to
> any port {67 68}
> Also disabling pf altogether.
Tried that too - nogo however.
--
Eike Lantzsch ZP6CGE
Zuviel Zucker ist ungesund. Daher:
Tragt den Zuckerberg ab!
