Ahh.. how would _any_ software that uses IP (TCP or UDP) be able to "bypass" pf? Doesn't pf operate at layer 2 and 3? AFAIK, DHCP still ends up heading out of the client or server over the network as UDP packets on ports 67 & 68. eg: http://www.dhcp-handbook.com/dhcp_faq.html#wppdd
Andrew --- Bj�rn Ketelaars <[EMAIL PROTECTED]> wrote: > > Does your dhcpd server listen on wi0 ? > > > > /Sigfred > > > > > > On Saturday 02 October 2004 18.28, you wrote: > >> I'm trying to block wireless clients in using my DHCP-server. The > >> problem is that these clients are still able to retrieve > IP-information > >> from the DHCP-server. If I understand the hereby included pf.conf, > >> everything (except UDP domain and TCP ssh) is blocked into > entering > >> $wir_if (which comes from $wir_if:network). Doesn't this also mean > that > >> an DHCP-request is blocked? Any suggestions in what I'm missing? > >> > > > > Hello, > > Indeed does the DHCP-server listen on wi0...If I understand correctly > now > the DHCP daemon is written to use pcap instead of network sockets. > This > means that the offers send out by the daemon can not be filtered(?) . > > Quote from another user... > > "I know that the dhcp* subsystem, was fundamentally written using > pcap, > so that it did not use normal network sockets to request and accept > answers, at least I know that the dhcpclient worked this way for > sure. > I'm not sure that the dhcpd daemon worked this way, so this is > something that deserves some follow-up... The dhcpclient in OpenBSD > changed this in 3.5, I know because I had to put pf rules in place > for > the client to work on my DSL public interface. The dhcpd server may > well use proper sockets at this time..." > > A simple solution to this problem would be to remove wi0 from > dhcpd.interfaces, but I wonder; is it 'wise' to give daemons the > option to > 'bypass' pf? > Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
